Require private settlement and preserve Chat payment recovery

[gstohl]

New RFQ and Chat offer settlements could expose amounts through public funding/OPEN outputs or send only one side of a swap. Current app, SDK, operator and localnet entrypoints now reject those paths before wallet, proof or funding side effects. The default RFQ page shows confidential availability; earlier maker inventory, claims/refunds and receipt reconciliation remain recoverable.

Chat payments now pair an encrypted transfer with an unfunded, proof-bound encrypted memo using a fixed helper token argument. Payment submission snapshots reviewed actions across callbacks, and an unknown wallet response preserves the payment attempt fence. Confidential escrow remains development-only: real STARK proofs, independent wallet support and mainnet activation are still pending. Historical mainnet contracts and receipts cannot be changed by this release.

New Chat invoices bind their network before sharing. Imported links reconcile with older network-scoped records without weakening term checks or clearing payment fences. Renamed the component directory and stylesheet to src/components/chat and chat.module.css, updating imports and documentation.

Updated capability metadata, guides and browser regressions; lazy-loaded Chat to keep the production entry within its existing bundle budget. Artifacts remain fully ignored.

Validation completed locally:

• Full application/package, local-control, evidence, release and supply-chain tests.
• Production build, bundle budget, browser leak and eight-route CSP checks.
• Local real-pool contract execution: encrypted STRK/ETH Chat payments, exact recipient balances, no public payment legs, and replay rejection (simulated proof facts).
• Earlier maker reservation release, withdrawal, deactivation and reconciliation on disposable devnet.
• Confidential availability and maker recovery browser regressions.
• Localnet Chat: encrypted message delivery, blocked one-sided offer acceptance, and a separate encrypted invoice payment in one wallet batch.
• Six localnet policy browser regressions: legacy routes and invoice handoffs cannot reopen settlement, all nine raw RFQ starts reject before funding, and historical operations metadata remains available.
• Complete eleven-stage localnet browser journey: composite/private invoice payments, blocked offer/escrow execution, key and draft recovery, multi-recipient delivery, responsive layouts and device cleanup.
• Signed-link reconciliation in both discovery orders, including reserved and unknown payment attempts; wrong-network and altered terms reject.