Verify wallet identity before operations

[KevinMehrabi]

Summary

• bind each prepared transaction to the wallet owner, Beacon account identifier, connection revision, pool recipient, network type, chain ID, and canonical RPC URL
• re-read Beacon's active account before and after RPC chain-ID verification immediately at the requestOperation boundary
• inspect every operation in the completed batch before forwarding it, allowing only configured pool/token contracts and requiring recipient, owner, and approval-owner addresses to match
• compare CUSTOM networks by canonical RPC identity instead of treating every CUSTOM account as equivalent
• clear transactions, quotes carried by transaction state, balances, and in-flight submission guards on account changes, reconnects, disconnects, or canonical network changes
• reuse the same Beacon client creation, subscription, and disposal helpers for connect and auto-reconnect paths

Why

An active-account subscription alone cannot guarantee that the account and network used while a transaction was prepared are still the ones Beacon will sign with. A wallet switch, reconnect, custom-network mismatch, or delayed network change could otherwise leave stale owner or recipient data in the operation.

Impact

A mismatch now fails closed before Beacon receives an operation request and invalidates the stale wallet-derived state. Matching submissions continue through the existing adapter and confirmation lifecycle.

Integration

This branch is independently based on trunk. PR #261 also changes the wallet transaction lifecycle, so whichever PR merges second should be rebased while preserving both the quote-revision guard and this request-boundary identity guard.

Validation

• npm run verify
  • production audit threshold passed (12 low, 2 moderate; no high or critical)
  • TypeScript passed
  • 23 suites / 75 tests passed
  • optimized production build passed
• changed-file ESLint passed with zero warnings
• Prettier check passed
• git diff --check passed

Closes #247