chore: release v0.12.0

[github-actions]

This PR was opened by the Changelogs release workflow.

When you're ready to release, merge this PR and the packages will be published.

---

0.12.0 (2026-07-29)

Minor Changes

• Added automatic native TIP-1034 channel top-ups before session vouchers exceed the current deposit, with credentials bound to each active WebSocket challenge across reconnects. (by @brendanryan, #366)
• Support Tempo Wallet P-256 access keys for charge payments and expose the
• shared store.json loader for native command-line clients. (by @brendanryan, #366)
• Add atomic stablecoin auto-swaps for native TIP-1034 session opens and top-ups,
• including the required Stablecoin DEX approval for charge and session payments. (by @brendanryan, #366)
• Add a Charge-only payment provider backed by the canonical Tempo Accounts
• store.json, with lazy access-key selection and no separate signing mode. (by @brendanryan, #366)

Patch Changes

• Continue retrying distinct charge challenges within the configured payment
• retry limit, matching MPPx and allowing sponsored servers to rotate challenges
• that were rejected before settlement. (by @brendanryan, #366)
• Match MPPx and Tempo fee sponsorship by encoding P-256 charge and TIP-1034 management credentials as sender-signed 0x78 envelopes. (by @brendanryan, #366)
• Authorize canonical application WebSockets with their advertised opening amount,
• and provide a top-up-aware authorization path for full reusable channels. (by @brendanryan, #366)
• Resolve persisted Tempo Wallet key authorizations against the Account Keychain before signing. Already-authorized access keys now omit the one-time authorization instead of failing fresh charge or session transactions with KeyAlreadyExists. (by @brendanryan, #366)
• Update the Tempo SDK revision so fee-payer relays can select the transaction fee token. (by @brendanryan, #366)
• Load pending Accounts SDK key authorizations from the shared Tempo Wallet store so native Rust clients can provision a fresh access key with their first transaction. Open a fresh session after access-key rotation instead of trying to reuse a channel bound to the previous voucher signer. (by @brendanryan, #366)