fix: WALLET-1394 — keep the approval window out of reuse during a Ledger confirmation

[ost-ptk]

Fixes WALLET-1394.

The bug

An already-permitted Ledger device opens no permission window, so the device call runs in the page inside the shared approval window. When the next dapp request arrives, that window is reused — and reuse runs tabs.update(tab.id, { url }) on its tab (create-open-window.ts:100-110), a full navigation. ledger is a per-document singleton (libs/services/ledger/ledger.ts), so the navigation destroys the document, the HID session and the pending signTransaction promise together.

Confirmed on hardware, 3 runs. The ticket describes a second mechanism — the signature reaching sdk-response-to-tab and being dropped by the supersede tombstone — and that one is real too, but it happened in only 1 of 3 runs. Which one wins is a race with how fast the replacement page commits its navigation (bundle cache, disk, load). Both end in signResponse({ cancelled: true }) to the first dapp.

This matters for the fix: nothing on the tombstone side can help, including WALLET-1364 P2 #10 — in the dominant case there is no longer anything to deliver. Only preventing the reuse works.

PR #1427 / #1462 covered only the other path, where a separate permission window gives the request a second display and the reuse leaves it alive.

The fix

• awaitingDeviceConfirmation on the open Request descriptor. Deliberately not a slice-level set: the tombstone replaces the whole entry and windowDetachedFromRequests shrinks windowIds, so the flag cannot outlive what it describes and nothing has to remember to clear it.
• selectIsWindowBusyWithDevice(state, windowId) composes the answer from the request side.
• openWindow withholds the tracked window while it is busy. Passing null redirects the reuse rather than suppressing it: the new-window branch still runs setWindowId (create-open-window.ts:154), so the shared slot retracks to the newcomer and only the protected window leaves the rotation.
• UI half: runWithDeviceConfirmationReported(requestId, run) brackets the device call. The bracket lives in its own module for the reason register-ledger-permission-window.ts does — there is no React-hook harness in this repo, and a start without its end would withhold the shared window for the rest of that request's life. It also gives the previously un-awaited ledgerAction() a catch.
• The action is intercepted in handleReduxAction, not added to FORWARDED_ACTION_TYPES (which checks no sender at all). Gates: isTrustedUiSender plus payload.requestId === recoverRequestId(sender.url) — the same pair closeLedgerFlowWindows uses, so a page can only speak for the request its own URL names.

Reviewer notes

Deliberate behaviour change in the permission-window flow. During the device call the request's windowIds is [shared, permission], so both now read as busy and a second request opens a third window instead of reusing the shared one. Previously the reuse navigated the shared window and the request merely survived it. Strictly safer — the waiting screen is no longer navigated away — but it is a change, and it is pinned by a selector test.

Residual race, knowingly left open. The flag is dispatched from the page and reduced in the background one runtime.sendMessage hop later. A second dapp request processed inside that hop (single-digit ms) still reuses the window. Previously the exposure was the entire device confirmation — seconds to minutes.

It was not closed by awaiting the dispatch ack, though the ack does mean the flag is in the store (background/index.ts:216 responds only when the result carries a response key, and the branch dispatches synchronously before returning). The drop paths return { handled: true } with no response key, so their promise never resolves — awaiting it before the device call would mean that any future tightening of the gate silently stops Ledger signing altogether. Bad trade against a millisecond window. Closing it properly means moving "this request is Ledger-signed" into the background, which it could derive from signingPublicKeyHex plus the vault at window-open time; that is a wider behaviour change and belongs in its own ticket.

A burst opens one window per request while the device is busy. The slot is only rewritten in the windows.create callback, so several requests arriving during a Ledger confirmation all see "tracked but busy" and each opens its own window. This is not new machinery — the same thing happens on base whenever no window is tracked yet (selectWindowId is null at cold start, so concurrent calls all take the create branch and each calls setWindowId); what changes is the condition that triggers it. Base collapsed such a burst into one window only by cancelling each previous request in turn, which for a Ledger confirmation is the exact P0 this PR exists to stop. Bounded near MAX_STORED_PAYLOADS for sign; signMessage has no equivalent cap, which is a pre-existing gap of its own.

One line is covered only by the manual test: the wiring at use-ledger.ts:135. Reverting it to a bare ledgerAction() leaves the whole suite green — same gap registerLedgerPermissionWindow lives with, for the same reason.

Testing

tsc, lint, format:check, knip clean; 1047 unit tests pass; the coverage gate passes (windowManagement 100%, handlers above its floor).

Manual, on a real Ledger with the HID permission already granted (so no permission window appears — that is the precondition for this bug):

1. Dapp A → sign from a Ledger account, stop at "Confirm on device".
2. Dapp B (second tab) → signMessage.
3. Before: A's window is repainted with B's request; A's dapp receives cancelled: true ~250 ms later; pressing Approve on the device does nothing. After: A's window is untouched, B opens its own window, A signs through, then B signs through.

Found while testing — not fixed here

Two Ledger flows can now be live at once, which was unreachable before this change because the second request used to consume the first one's window. If the user leaves A waiting on the device and presses Sign with Ledger in B, B's document opens the device and sends its own APDUs while A's prompt is up. The Casper app has no queue: it tears down A's prompt and answers B with 0x6985, so B shows "You rejected to sign the deploy" (which the user did not do) and A can no longer be completed — the window has to be closed and the flow restarted.

This is contention over one physical device, not window management, and it is not made worse by this PR: previously A was lost unconditionally and silently, whereas now it is lost only if the user deliberately starts a second signing flow, and the failure is visible. Note that LedgerEventStatus.WaitingToSignPrevDeploy already exists with exactly the right copy for this situation — B just never gets to it.

It cannot be arbitrated inside a page (the ledger singleton is per document); the only shared authority is the background store, which is where this PR's flag already lives. It also affects the internal flows (transfer, staking, import-from-ledger), which carry no requestId and so are not covered by that flag.

Investigated and filed as WALLET-1429. Two findings from it are worth knowing while reviewing this PR:

• Request A hangs rather than fails. There is no timeout anywhere on the signing path — TransportWebHID never consults exchangeTimeout, and exchangeAtomicImpl's 15 s unresponsiveTimeout only emits an event. So runWithDeviceConfirmationReported's finally never runs and awaitingDeviceConfirmation stays set. The blast radius is still what this PR describes — the slot retracks to the newcomer's window and later requests reuse that normally, so it costs exactly one held window until A's window is closed, not one per request.
• LedgerEventStatus.WaitingToSignPrevDeploy is unreachable, and not only because of ordering: its trigger returnCode === 65535 (ledger.ts:135) cannot fire for a busy device, since Zondax's processErrorResponse returns the real status code whenever the error carries one and 0xffff only as the fallback for errors without one. Any future fix leaning on that copy must trigger it from a wallet-held fact.

[Comp0te]

Read this against the WALLET-1394 failure it closes, along with the reducer, selector and openWindow tests it adds. The fix is sound and the tests pin it. The comments below all sit on one seam: awaitingDeviceConfirmation is a single boolean whose truth has to survive a message hop, a chain of browser round-trips, and any concurrent holder — each comment is one place where it does not.