Add verified X Chat plaintext reads and durable encrypted sends

[0thernet]

Outcome

Add signature-verified plaintext reads and durable encrypted sends for existing X Chat conversations through the official Chat XDK.

The current X adapter can expose subject-bound conversation metadata and raw encrypted events. Plaintext and send support need a separate, explicit security boundary around X Chat identity recovery, historical signing keys, conversation-key reconstruction, and exact encrypted retry payloads.

Scope

• Add messaging.chat.read for verified plaintext from existing conversations, including explicit per-event omissions.
• Add messaging.chat.send for reviewed text to an existing direct conversation using a verified current conversation key and one persisted encrypted body.
• Pin and integrity-check the supported Chat XDK, Juicebox SDK, and their WASM assets.
• Read the Chat PIN only through a hidden interactive or explicit secret-broker boundary; never accept it in arguments, JSON, environment variables, plans, receipts, or logs.
• Run one XDK lifecycle in one short-lived subprocess per operation and zero caller-owned PIN and conversation-key bytes on every exit path.
• Require exact OAuth-subject binding, registered-key matching, historical signing-key verification, and rejectUnverified behavior.
• Reconcile indeterminate sends by the original message ID and exact encrypted body. Never re-encrypt an automatic retry.

Non-goals

• New-conversation creation
• Automatic identity provisioning or key rotation
• Group administration
• Chat media
• Background automation without a reviewed noninteractive secret-broker contract

Acceptance criteria

• Official synthetic vectors cover recovery, verified decryption, tampering, stale-key replay, conversation binding, and exact send-body construction.
• Old events verify with required historical keys and fail when those keys are absent.
• PINs, realm tokens, private keys, conversation keys, mutation ciphertext, and unverified plaintext never enter durable state or diagnostics.
• Two opted-in low-stakes accounts pass read, send, wrong-PIN, stale-key, bad-signature, timeout, crash, and indeterminate-response drills.
• The capability is documented as stable only after the live gate passes on the supported runtime.