[DOCS] client-sdk: Teecryptor decrypts today, not the Threshold Network

[haimbj1]

DOC-66

The Client SDK tab named the Threshold Network as the component that decrypts today. It is not. Teecryptor decrypts CoFHE ciphertexts and signs the results, inside a hardware-attested TEE. The Threshold Network is a future plan.

This fixes all 21 mentions across 6 Client SDK pages, using the wording already merged in the Deep Dive tab (PR 43).

What changed:

• overview: decryption goes to Teecryptor; one sentence defines it and links the Deep Dive page.
• mental-model: the SDK asks Teecryptor to decrypt and seal to the ACP's sealing key.
• migrating-from-cofhejs, end-to-end: decryptForTx returns a Teecryptor signature.
• decrypt-to-view, decrypt-to-tx: the polled service, the request id, and the 404 submit retry all name Teecryptor.

The runtime behaviour on the two guide pages was verified, not renamed blind. Teecryptor serves the /v2/decrypt and /v2/sealoutput submit and poll routes, returns request_id, and answers 404 when the ciphertext is not found. The SDK 0.7.1 build matches: onPoll, an empty requestId during submit retries, and a 10000 ms default for set404RetryTimeout.

The chain config field is still spelled thresholdNetworkUrl in the SDK. Both setChainId sections now name the Teecryptor URL and keep that identifier in backticks, so a reader can still find the field.

No other tab is touched. Separate tickets cover the FHE library and Tutorials tabs.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
fhenix	🟢 Ready	View Preview	Sep 3, 2026, 5:00 PM