fix(claim): report Claim All progress in place instead of taking over the screen

[WiktorStarczewski]

Tapping Claim All pushed a full-screen progress page and left you there. That page follows a single transaction (useTransactionRow(txId)), while Claim All queues one consume per faucet and only the first id survives (batchTxId = batchTxId ?? groupTxId) — so it could only ever show one of them, and would assert a confident, wrong receipt while the other faucets were still queued or already failed.

Claim All now reports progress on the pending list itself, which keeps a control reading "Claiming…" while the batch is in flight.

Claiming a single note is unchanged. That is one transaction, so the progress screen represents it correctly — it still opens, still shows its receipt (sender, total consumed, note ids, fee, explorer link), and its own interval still drives the queue. #834's "Claiming…" control on a row also still opens it.

Removing the navigation from the batch path removed a load-bearing side effect, which is most of this diff:

• The queue needed a driver. Off-extension that page's interval was the only thing turning the FIFO loop from the batch path — claims would sit Queued forever. Claim All now starts the background processor directly, the shape Explore.tsx:167-171 has always used to auto-consume without navigating.
• The summary went blank. Every claiming note drops out of unclaimedNotesCount, which gated the CTA — so the user tapped Claim All and watched the button vanish with nothing in its place.
• A failed claim went silent. The recheck only re-ran when claimable ids changed, and a failed consume leaves the note claimable with the same id. A second signature over the notes being claimed covers the normal case; a bounded recheck at 1s/4s/10s after queueing covers a consume that fails faster than the list can render it (an offline claim goes Queued → Failed in well under the 3s poll, so isBeingClaimed is never true in any sampled render).

Two ids for the CTA, on purpose

claim-all-button keeps meaning "an actionable Claim All" — the E2E helper treats that id being visible as permission to click (wallet-page.ts:1881-1883), and isVisible() is true for a disabled button, so a disabled control under that id would make 23 specs click something they cannot action and wait for actionability until timeout. The in-flight state is claim-all-status, the same split #834 made for the row's control.

Verification

10,089 tests / 607 suites. tsc, eslint and the i18n gate clean. No new i18n keys — claiming already existed.

Sabotage-verified independently: dropping the queue driver fails the batch test; reverting the summary gate fails the in-flight test; restoring the batch navigation fails the no-navigate assertion; removing the post-claim recheck fails the fast-failure test.

The pre-existing test that asserted the batch navigate is converted, not deleted — it now asserts the driver runs and no navigation happens.

Not verified on a real fee-charging chain; the claim path's timing here is asserted through mocks.

Reviewers: the queue driver is load-bearing — if startBackgroundTransactionProcessing(signTransaction, false, zustandProvider) is wrong off-extension, Claim All silently never processes. It is copied from Explore's auto-consume, which claims on Home today with no navigation.