fix(background): cap concurrently open requests

[ost-ptk]

Description

Hardening on top of the sweep. sign and signTypedData already refuse at MAX_STORED_PAYLOADS = 10 before registering a request; connect, switchAccount, signMessage and decryptMessage had no cap at all — supersede was the only brake, and CANCEL_GRACE_MS = 250 lets a burst register everything first. With the mirror persisting open rows, an unbounded burst would also be a session-storage write-amplification vector.

The sweep (previous PR) is the prerequisite that makes a cap safe: without it, a pinned-open row would consume a cap slot for the whole browser session, turning frozen states into a slow denial-of-approvals.

What changed

• MAX_OPEN_REQUESTS beside MAX_RESPONDED_TOMBSTONES in windowManagement/reducer.ts. Steady-state concurrency is ~1–2 (one shared approval window plus the Ledger second window) — the cap only bounds the 250 ms burst.

• windowRequestOpened refuses the write at the cap and returns state unchanged (reference-identical). Open requests are never evicted, and a refused write consumes no ordinal.

• A silent reducer refusal produces no response by itself, so each of the four capless handlers gets an explicit post-dispatch re-read — the analogue of the existing getPayload(...) == null check. On refusal the dapp receives that method's existing negative shape and openWindow is never called.

• Cap only — no errorCode. Four of the six response shapes cannot carry one (connectResponse/switchAccountResponse are bare booleans; signMessageResponse/decryptMessageResponse are {cancelled} | {…}), and their *Error creators lack error: true, so the SDK would resolve the dapp promise instead of rejecting (the WALLET-1346 masking defect). Widening the wire shapes is a separate ticket.

• The mirror's write cap is tightened from an undocumented headroom to the enforced relation MAX_SESSION_ROWS = MAX_RESPONDED_TOMBSTONES + MAX_OPEN_REQUESTS, with a test asserting it.

• sign/signTypedData (second commit): the same post-dispatch re-read applies to them too — at the cap they refuse with their own MAX_STORED_PAYLOADS-style response (errorCode: tooManyPendingRequests, a real error channel) and never open a window. Their payload actions are dispatched before windowRequestOpened, so on refusal the branch also dispatches windowRequestResponded({requestId}) — the WALLET-1418 orphan mechanism the vault reducer already keys off — reclaiming the stored payload immediately (the windowManagement case no-ops for an id with no open row). Without this, ~20 capless opens plus 10 refused signs would pin every payload slot and kill signing for all origins until the next unlock (review finding). The MAX_STORED_PAYLOADS refusal itself fires earlier and is byte-unchanged.

• The four capless methods still answer a cap refusal with their negative shapes only — an explicit errorCode for them is WALLET-1436 (wire-shape change + the WALLET-1346 masking fix).

  On the number itself: MAX_OPEN_REQUESTS = 20 is not arbitrary — the vault already admits 2 × MAX_STORED_PAYLOADS (deploys + EIP-712 maps, 10 each) concurrently open sign-family requests, so any smaller cap would fire before the payload caps in the all-sign-family case. That floor is necessary, not sufficient — the four capless methods consume open slots outside its quantifier (review finding; the comment and test are scoped accordingly).

Verification

• npx jest src/background/ — 936 tests pass; npx tsc --noEmit clean; eslint/prettier clean.
• windowManagement/reducer.ts stays at 100/100/100/100; handlers/sagas floors hold.
• Pinned by tests: at the cap the write is refused and state returns reference-identical; each refusal produces the method's negative response and no openWindow call; a completed request frees a slot; sign's existing refusal still fires first; the MAX_SESSION_ROWS relation.

Linked tickets

WALLET-1419

Checklist

• Make sure this PR title follows semantic release conventions: https://semantic-release.gitbook.io/semantic-release/#commit-message-format

• If the PR adds any new text to the UI, make sure they are localized — no UI text added

• Include a screenshot or recording if implementing significant UI or user flow change — background-only, no UI change

• When this PR affects architecture changes wait for review from Dmytro before merging

[Comp0te]

Read the cap end to end — the reducer's refusal path, the six handler read-backs, the session mirror, and the tests — against the merge base. The cap itself is the right shape and the ordinal/no-evict invariants hold. The comments below run along one seam: the refusal is a silent state transition, and the code around it hasn't caught up. One path strands an already-accepted payload; two texts assert the strand can't happen; two tests restate definitions rather than exercise the boundary; and the count that drives the refusal is blind to both origin and provenance.