Storage Resilience FY26H1

### Goals

**Goals**
**Eliminate storage-related crashes for users** — no more failed wallet init / "background connection unresponsive" from corrupt storage.
**Never lose user data** — keep a complete, redundant backup and silently restore *all* application state after corruption, with no user-facing recovery flow.
**Reduce state-corruption risk at the source** — cut write frequency and volume, and stop large "cache" data sharing a failure domain with the vault.
**Make failures visible** — know the true corruption rate and which state is at fault, instead of silent data loss.
Fail gracefully when storage genuinely can't — when the disk is full or broken, degrade visibly rather than losing writes silently.

### Order of work
**Priority 1**
- [ ] Storage Resilience Quick Wins
- [ ] E0: Write & idle instrumentation + corruption metrics (baseline) https://github.com/MetaMask/metamask-extension/issues/44250
- [ ] E1: Migrate StorageService to IndexedDB https://github.com/MetaMask/metamask-extension/issues/44251
- [ ] E2: Controller state audit: application vs cache https://github.com/MetaMask/metamask-extension/issues/44252
- [ ] E4: Zero Controller Writes While Idle https://github.com/MetaMask/metamask-extension/issues/44253

**Priority 2**
- [ ] E3 Migrate cache state out of controllers https://github.com/MetaMask/metamask-extension/issues/44256
depends on E1 https://github.com/MetaMask/metamask-extension/issues/44251 and/or E0 https://github.com/MetaMask/metamask-extension/issues/44250 https://github.com/MetaMask/metamask-extension/issues/44256

**Priority 3** design + phased rollout
- [ ] E6 Detect Silent State Loss & Improve Corruption Metrics https://github.com/MetaMask/metamask-extension/issues/44258
- [ ] E7 Degraded persistence mode (quota / no-space UX) https://github.com/MetaMask/metamask-extension/issues/44259
- [ ] E10 Full Application-State Backup + Redundant Storage https://github.com/MetaMask/metamask-extension/issues/44311

**Priority 4 — Parked pending decision**
- [ ] Storage-model rebuild: generated keys + manifest replica set (ADR-0008)

**Descoped:** ~~E5: Surgical / partial recovery flow (#44257)~~ — see item 2.

Start by reviewing the linked Priority 1 issues E0, E1, E2, and E4, then the dependent and later-priority items. The payload names no source files or tests, and this issue covers a broad storage-resilience program rather than one isolated change. Done means addressing the relevant goal, such as preventing storage crashes, preserving and restoring application state, measuring corruption, or failing visibly when storage cannot persist.

Written by the indexing model from the issue text.