Recover or fail safe when the MV3 service worker terminates mid-review

[knytcomics-ui]

Summary

pendingDecisions (src/background/background.ts:13) is an in-memory Map. Manifest V3 service workers are terminated by the browser after ~30s of inactivity or under memory pressure; if that happens while a popup is open awaiting DECISION_MADE, the resolver closure is lost and the dApp's request hangs forever even if the user clicks Proceed.

Current Behavior / Relevant Code

• No chrome.storage.session or chrome.alarms usage anywhere in the background worker to keep it alive or persist state across restarts.
• manifest.json:9-11 declares a standard service_worker background with no way to opt out of MV3's termination model.

Why This Matters

This is a correctness bug specific to MV3's lifecycle model, not something that shows up in a quick manual test (the worker often survives short-lived local testing) -- it will manifest intermittently in the field as 'the extension just doesn't respond' reports.

Proposed Solution

• Persist pendingDecisions metadata (requestId to windowId) to chrome.storage.session so it survives worker restarts within the browser session.
• On worker startup, reconcile chrome.storage.session against currently open windows via chrome.windows.getAll and resolve/clean up orphaned entries.
• Add an integration-style test simulating a worker restart between SIGN_REQUEST and DECISION_MADE.

Acceptance Criteria

• A simulated service-worker restart between request and decision does not hang the caller.
• Documented in README under 'How the Pieces Connect' as a known MV3 constraint and its mitigation.

Definition of Done

• npm run lint, npm run typecheck, npm test, and npm run build all pass locally and in CI
• New or changed behavior is covered by unit tests (and integration/E2E tests where the change touches interception, background messaging, or the popup)
• Any user-facing or architectural change is reflected in README.md
• No regressions to the existing test suite or existing tier/interception behavior

How to Claim This Issue (Application Process)

1. Comment first. Post a short implementation plan on this issue — your proposed approach, the files you expect to touch, and any open questions — before writing code. This prevents duplicate effort and lets a maintainer flag concerns early, which matters especially for an issue at this complexity level.
2. Wait for assignment. A maintainer will review your plan and assign the issue to you, typically within 48 hours. Please do not open a draft PR before you're assigned.
3. Stay active. If there's no visible activity (commits or comments) for 10 days after assignment, the issue may be unassigned and reopened to other contributors.
4. Submit a scoped PR. Reference this issue (Closes #<issue-number>), keep the diff scoped to the acceptance criteria above, and ensure all CI gates pass before requesting review.
5. Engage with review. Respond to review feedback within a reasonable timeframe; PRs with no response after 7 days may be closed pending resubmission when you're ready to pick it back up.

---

Category: Security & Interception Robustness
Estimated effort: L (large, ~1-2 weeks)
Difficulty: Advanced — this issue assumes familiarity with the codebase's MV3 service-worker architecture, the Freighter interception protocol, and/or the Stellar SDK.