Resolve XCHandles safely in every recipient flow

Parent: #867
Depends on: the trusted resolver issue under #867.

Summary

Accept raw bech32 addresses or @handle inputs through one backend recipient pipeline and use it everywhere Sage accepts a recipient.

Scope

• Add a shared backend input type/path that resolves and validates addresses and XCHandles before transaction construction.
• Integrate it into XCH/CAT sends, NFT/DID/option transfers, clawbacks, bulk sends, offer-related recipients, WalletConnect, and Sage app/RPC surfaces.
• Preserve the user's original handle alongside the resolved bech32 address in previews and confirmations.
• Re-resolve at final approval/submission. If the verified mapping changed since entry or differs from the cached trusted value, block silent submission and require explicit acknowledgement.
• Show verified, cached/offline, stale, changed, expired, and unavailable states without treating API reachability as proof.
• Keep raw-address behavior backward compatible.

Acceptance criteria

• Every recipient surface uses the shared pipeline; no UI-only resolution bypass exists.
• Confirmations show both handle and resolved address.
• Mapping changes between entry and approval cannot silently redirect a transaction.
• Multi-recipient transactions report resolution failures per recipient.
• WalletConnect/app requests receive structured verification and warning data.
• Tests cover raw addresses, valid handles, stale/offline cache, changed mappings, unsupported networks, and mixed bulk recipients.

Start with the trusted resolver issue under parent #867, then map every recipient surface listed here: sends, transfers, clawbacks, offers, bulk sends, WalletConnect, and Sage app/RPC requests. Define the shared pipeline and its verification states before integrating it. Done means all surfaces use it, confirmations preserve handle and address, changed mappings cannot silently submit, and the listed recipient-resolution tests pass.