fix(background): rank tombstone eviction by ordinal, not key order

[ost-ptk]

Description

windowRequestResponded evicted the oldest tombstones by filtering Object.keys(requests), on the stated assumption that "Insertion order = the order requests were first registered".

That is false for the keys this map actually holds. requestId is page-generated (generateRequestId, src/content/sdk.ts), so an integer-like id such as "42" is one the wallet accepts — and integer-like keys enumerate ahead of every string key in ascending numeric order, however recently they were written. A dapp numbering its requests could therefore have its newest tombstone evicted first while genuinely older ones survived, and MAX_RESPONDED_TOMBSTONES stopped bounding what it was meant to bound. Losing a tombstone early means the response dedup no longer drops a late duplicate for that id.

What changed

• Both arms of Request carry a seq. The open row is stamped at registration; the tombstone is restamped at response time (nextSeq over the pre-update map), because the cap's stated policy is eviction by when a request was answered — inheriting the registration ordinal would let answering the oldest-registered request evict its own just-written tombstone (review finding, pinned by a dedicated test).
• Eviction ranks on seq ascending instead of on key order.
• The ordinal is derived from the map (max + 1) rather than held in a counter field. A counter would be state that survives nothing: after an MV3 service-worker restart it would resume at zero and re-issue ordinals the map still holds.

Why not reuse the vault's helpers verbatim

vault/reducer.ts solved the same problem for its payload map (WALLET-1418), but its orderOldestFirst additionally handles rows written before the field existed, ranking unstamped hoisted keys newest. Nothing here can be unstamped — every row is stamped by this reducer at birth — so those branches are not ported. On a file held to 100% coverage they would be unreachable code demanding tests.

The helpers were also deliberately not moved into request-map.ts: collectCoverageFrom matches src/background/redux/**/reducer.ts but not request-map.ts, so relocating them would silently drop covered code out of the enforced universe for both slices.

Verification

• npx jest src/background/redux/windowManagement/ src/background/handlers/ src/background/open-window.test.ts src/background/redux/sagas/vault-sagas.test.ts — 22 suites, 394 tests pass.
• npx tsc --noEmit — clean.
• windowManagement/reducer.ts coverage: 100% statements / branches / functions / lines.
• The regression test was proven to fail against the old ranking: with Object.keys restored, "42" is evicted while the genuinely older r0 survives.

Context

This is a prerequisite for the rest of WALLET-1419. The planned fix mirrors windowManagement's request state into chrome.storage.session so it survives a service-worker restart; that mirror round-trips through a JSON-shaped structure, which re-applies the same key hoisting, and its write-side row cap needs an age order to drop by. The ordinal has to exist first.

The eviction bug is live on develop independently of that work, so this stands on its own.

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]

Reviewed the ordinal-based tombstone eviction and the fixture updates that follow it. The ranking change itself is right — enumeration order was genuinely hoisting integer-like keys — and the tests pin that. One comment below, on what the ordinal is measured from.