Consider splitting background.ts (1511 lines)

[chrischall]

`packages/extension-core/src/background.ts` is 1511 lines — by far the largest file in the repo. It currently bundles:

• The pure decision function `handleServerHello` (security-critical, well-isolated, ~250 lines)
• The local `declare const chrome` for chrome.* APIs used by the SW
• All `chrome.storage.local` / `chrome.action` / `chrome.alarms` / `chrome.tabs` / `chrome.cookies` / `chrome.webRequest` handlers
• WS connect/reconnect/encrypted-frame routing
• Per-verb `handleXxxRequest` (fetch / read-storage / read-cookies / capture-request-header / read-indexed-db)
• The badge / auto-popup helpers
• `maybeBoot()` lifecycle wiring

Cohesive — most pieces touch the same shared state Maps. A naive split would create circular imports between request-handler modules and the shared-state module.

Reasonable split, if you do it

1. Extract `handleServerHello` (already pure) + supporting helpers into `src/handle-server-hello.ts` (~300 lines, cleanly testable today)
2. Extract per-verb handlers into `src/handlers/` — `fetch.ts`, `read-storage.ts`, `read-cookies.ts`, `capture-request-header.ts`, `read-indexed-db.ts`. Pass the per-mcpId scope tables as args (don't import them as module-globals)
3. Extract badge logic into `src/badge.ts` (~50 lines, self-contained)
4. Keep background.ts as the SW entry point: imports, lifecycle, WS plumbing, shared state Maps, small dispatchers

Cost / benefit

• Benefit: smaller files easier to reason about; `handleServerHello` unit-testable without SW boot scaffolding
• Cost: real refactor; touches every test that mocks `chrome.*`; risk of subtle behavior change in SW boot order

Worth doing the next time someone is in this file substantively (adding a new capability handler, refactoring trust storage). Not a standalone change.

[chrischall]

Audited during 0.8.0 work — current state holds. `background.ts` is now ~1530 lines (essentially unchanged from when this was filed). The 0.8.0 server-side work is concentrated in `packages/server` (typed errors, lazy-revive, bridgeHealth, capture-by-declaration), not in `background.ts` — so the issue's own trigger ("the next time someone is in this file substantively") still hasn't fired.

Deferring per the issue's own guidance. The four-step split proposed in the body still reads correctly when someone is eventually in here adding a new capability handler or reworking trust storage; `handleServerHello` would extract cleanly today as the lowest-risk first step (~300 lines, already pure), but doing it in isolation for its own sake isn't a clear win.