Storage Resilience E2: Controller State Audit: Application vs Cache

### What is this about?

## Goal
Classify persisted controller state so we know what's "cache-like" (large, high-churn, re-fetchable) vs application-critical (vault, accounts, permissions, contacts).

## Why
We can't prioritise migrations without this map. (H1, H2 — high)

## Success criteria
- Every persisted controller slice classified `critical | reconstructable | safely-degradable`.
- Ranked list of top-N controllers by (persisted-size × write-frequency) with a recommended action per slice.
- Classification metadata co-located with each controller, so it stays in feature-team control.

## Tasks
- [ ] Instrument per-controller persisted size + write frequency (reuse E0 / existing perf harness). Sizing options: (a) sampled on-write `JSON.stringify`; (b) `await navigator.storage.estimate()` before/after migrating each controller to IndexedDB one at a time ([Mark, reply 13](https://consensys.slack.com/archives/C0B8XGJLKHV/p1782838021500919?thread_ts=1782759629.293769&cid=C0B8XGJLKHV)).
- [ ] Snapshot production telemetry of controller-state size distribution.
- [ ] Publish a spreadsheet: every persisted controller with size p50/p95, write frequency, criticality, owner team.
- [ ] Draft a per-controller decorator/metadata API (e.g. `@persisted({ criticality, recoveryHint })`) — used by E5 and E8.
- [ ] Ratify classifications with each owning team (Wallet UX, Confirmations, Snaps, Assets, Networks, Notifications).
- [ ] Deliverable: `docs/extension-storage/controller-state-inventory.md`.

## Cross-team
Mark to open the conversation with Core Platform on the shared "data service" pattern (feeds E3).

## Dependencies
- **Depends on:** E0.
- **Unblocks:** E3, E5, E8.

### Scenario

_No response_

### Design

_No response_

### Technical Details

_No response_

### Threat Modeling Framework

_No response_

### Acceptance Criteria

_No response_

### Stakeholder review needed before the work gets merged

- [ ] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

### References

_No response_

Start by reviewing dependency E0 and the existing performance harness mentioned in the task. Inventory persisted controllers and determine how size, write frequency, criticality, and ownership can be recorded. Done means producing docs/extension-storage/controller-state-inventory.md, a ranked set of recommended actions, and agreed classifications with the owning teams.

Written by the indexing model from the issue text.