feat(wallet): tick the balance up when a scanned bill is claimed

[bmc08gt]

Put in Wallet dismissed the bill and left the user on the scanner. The money they had just taken only showed up the next time they opened the wallet, already counted.

The button now takes them to the wallet tab and the balance rolls up on arrival.

Why there's a coordinator for this

The roll needs a "before" to start from, and there isn't one by the time the wallet opens. tokenCoordinator.add credits the account when the bill is grabbed, several taps before the claim, so every flow the wallet reads has already moved.

WalletRevealCoordinator carries the pre-credit picture across that gap:

1. CodeScanDelegate captures the totals immediately before the credit.
2. claimReceivedFunds() arms the snapshot and dismisses the bill. It's a separate BillOperations method rather than a branch inside dismissBill(PutInWallet), because that same result also covers a grab timeout, a cancel, and a swipe-away, none of which is the user asking to see their wallet.
3. The wallet opens on the snapshot, holds it while the bill leaves, then releases to live values.

The header and each card's balance already draw through AnimatedNumberText, so the roll itself is just the rendered string changing. The claimed token's own card balance is held back too, so its number rolls in step with the total above it instead of sitting there already updated.

When the hold ends

The bill returns on a 600ms slide and the tab crossfades under it over 300ms. A hold that ignores both runs the balance up while it is still covered, spending the animation where nobody can see it.

So the reveal ends on the later of two clocks, both started at the tap: 450ms for the bill to clear, and 150ms from the wallet reporting itself drawn, so a tab that took a while to appear still shows the pre-claim figures instead of rolling them on its first frame. A reveal nobody collects releases itself after 3s, which bounds the whole wait and also means there's no logout or reset wiring to keep in sync.

This is the same sequencing as iOS's depositRevealDelay in code-payments/code-ios-app#697.

Only scanned bills route

A cash link is claimed from a link rather than from the scanner, so nothing is captured for it. arm() returns whether there was a snapshot, claimReceivedFunds() passes that back, and the decorator navigates only on true. The cash link confirmation dismisses where it stands, as it did before. iOS is aligning to the same exemption.

New card arrival

A claim in a currency the wallet didn't hold reaches TokenCardStack as arrivingMint, with arrivalHeld set while the reveal is up. The card is in the deck throughout, so the layout is final from the first frame; it just starts 40dp low and transparent, and rises into place over 900ms once the hold ends. Nothing around it moves. This is iOS's arrivalProgress effect, at iOS's own distance and duration.

The caller names the arriving card rather than the stack diffing its own token list. The case that most needs the animation, a wallet that held nothing so the stack was never composed, is exactly the one a diff can't see.

The mint-balance rewind applies only to a currency the wallet already held, so its card number rolls in step with the total above it. A card that is only now arriving has no earlier number to roll from and rises showing what it holds.

Tests

WalletRevealCoordinatorTest covers the capture/arm/hold/release cycle: a capture is consumed once so a second tap can't replay it, arming with nothing captured publishes nothing and reports false, a redraw part way through the hold doesn't extend it, and an uncollected reveal times out. Both clocks have a case — a wallet that draws straight away still waits out the bill, and one that takes longer than the bill still gets its beat on arrival. CodeScanDelegateTest asserts the ordering the whole thing rests on, that the snapshot is taken before the credit. BillPresentationDelegateTest covers both claim paths and checks the other PutInWallet dismissals leave the reveal alone.