Motivation

Second of two PRs from the spec. During a recent incident the chain-fusion signer could not sign for any user because OISY's backend ran out of TCycles. Users saw a raw, alarming toast:

Something went wrong while sending the transaction. / Ledger error: {"InsufficientFunds":{"balance":"45738950"}}

That number is OISY's backend cycles balance, not the user's token balance — but it reads like a wallet error. This PR replaces that raw leak with a calm message across every affected flow, and is stacked on #13144 (it reuses the isSignerCanisterPaymentError guard added there).

It also distinguishes a second payment failure mode: an exhausted per-user ICRC-2 allowance towards the signer. That is a per-user signing limit, not a wallet-wide outage, so an outage-style "it's on us, we're fixing it" tone would be wrong — it gets its own message.

Spec: docs/ai/spec-driven-development/specs/2026-06-18-impr-cfs-signing-error-toast-and-cfs-sign-event.md (Part A).

Note: base is feat/frontend/track-cfs-sign-event (PR #13144). GitHub will retarget this to main once that merges. Review only the commits on this branch (everything layered on top of the #13144 base).

Changes

• Add a new top-level sign namespace i18n (distinct from the dApp-signer signer namespace), translated into all supported languages (the 13 in the Languages enum; ar is unused → falls back to English). Two keys:
  • sign.error.unavailable — wallet-wide outage (e.g. backend out of cycles).
  • sign.error.limit_reached — per-user signing limit (exhausted allowance).
• signer.errors.ts: SignerCanisterPaymentError now records whether the underlying ledger error was a nested InsufficientAllowance, exposed via a new isSignerCanisterAllowanceError guard (alongside isSignerCanisterPaymentError).
• Add toastsSignerUnavailableOr({ err, fallback }) in toasts.store.ts: for a SignerCanisterPaymentError it shows sign.error.limit_reached (allowance) or sign.error.unavailable (any other payment failure) — without appending the raw ledger text (still consoleError-logged); otherwise it defers to the caller's fallback.
• Route the user-facing signer-error catch sites through it:
  • ETH send (token + NFT), BTC send, SOL send (keeping the mapSolanaErrorMsg fallback).
  • The central WalletConnect execute() wrapper in lib/services/wallet-connect.services.ts — covers WC personal_sign / eth_sign / sends / signPsbt for all chains in one place.
  • OpenCryptoPay's inline failedPaymentError (friendly/limit message for the payment cases; tracking keeps the raw message).
• Map Schnorr signer errors (getSchnorrPublicKey / signWithSchnorr): they previously threw the raw candid Err (stale TODO). The signer returns EthAddressError for Schnorr too, so they now route through the existing mapSignerCanisterGetEthAddressError — a PaymentError becomes a SignerCanisterPaymentError, so the new messages reach SOL signing like the ETH/BTC flows.
• Genuine user errors (invalid address, insufficient token balance, gas) keep their existing specific toasts.
• Add a self-describing, always-present event_code (success, cfs_payment_failed_backend_out_of_cycles, cfs_payment_failed_user_allowance_exhausted, cfs_generic_error) so "all payment failures" is filterable from one property (the cfs_payment_failed_ prefix), and move the event to a dedicated event_context=cfs (not the dApp-signer's signer). event_code (cause) and result_error_severity (alerting) are derived from one classification.
• On the allowance case, fire a best-effort background allow_signing re-grant (replenishSignerAllowance, new signer-allowance.services.ts) so the next attempt can succeed without a page reload -- non-fatal (never signs out), single-flight, no auto-retry. The allow_signing rate limiter stays the real per-user cap.
• Tag the cfs_sign event severity for the allowance case: result_error_severity = major (a per-user limit working as intended) instead of blocker, so it is not over-reported as an incident on dashboards (backend payment failures stay blocker, other signer errors critical).
• Document the behavior in PRODUCT.md.

Tests

• signer.errors.spec.ts: isSignerCanisterAllowanceError is true for Ledger{Withdraw,Transfer}FromError → InsufficientAllowance and false for the funds/other payment variants and non-payment errors; an allowance error is still an isSignerCanisterPaymentError.
• toasts.store.spec.ts: shows sign.error.unavailable for a non-allowance payment error, sign.error.limit_reached for an allowance error (neither leaks the raw ledger detail), and defers to the fallback for non-payment / nullish errors.
• signer.canister.spec.ts: getSchnorrPublicKey / signWithSchnorr map a returned PaymentError to a SignerCanisterPaymentError.
• Existing EthSendTokenWizard / BtcSendTokenWizard / wallet-connect.services specs still pass.
• prettier, eslint --max-warnings 0, i18n:types + i18n:keys, and svelte-check (no problems in changed files) pass.

Divergence from the spec

The spec (docs/ai/spec-driven-development/specs/2026-06-18-impr-cfs-signing-error-toast-and-cfs-sign-event.md) has been updated in this PR to match what shipped; the items below summarise the notable deviations from the original draft.

• Per-user allowance message added beyond the original spec: an InsufficientAllowance payment error is a per-user signing limit (the caller's ICRC-2 allowance towards the signer is exhausted), distinct from the wallet-wide cycles outage, so it gets sign.error.limit_reached rather than the outage message. The distinction is frontend-only — the variant is already present in the signer's candid, so no CFS change is needed.
• Swap flows left unchanged: SwapEthWizard (and siblings) already surface a generic swap.error.failed_unexpectedly message — the raw error only goes to tracking, never the UI — so there was no raw-text leak to fix. EIP-2612 permits surface through these same swap/approve catches, so they're covered by the existing generic message.
• WalletConnectReview.svelte not touched: its catch handles session approve/reject, which does not call a signer method, so it can't receive a SignerCanisterPaymentError.

🤖 Generated with Claude Code — model: Claude Opus 4.8 (claude-opus-4-8)