Storage Resilience E3: Migrate Highest-Impact Cache State Out of Controllers

### What is this about?

## Goal
Move the worst size×churn offenders into dedicated data services (outside controller state, own persistence), removing them from the corruption blast-radius.

Migration priority:
1. Largest data sets first — storage service, PhishingController.
2. Frequently-updated sets — balances.
3. Anything written while the extension is **idle with the sidepanel open**.

## Why
Once E2 ranks the offenders, migrating them out cuts controller-state write volume and stops large cache values sharing a failure domain with the vault. (H1, H2 — high)

## Success criteria
- Top 3 cache-like slices migrated out of controller state.
- Post-migration reduction in controller-state write volume validated against the E0 baseline.
- No user-facing data loss or first-load regression.

## Migration safety (applies here and to E8)
- [ ] Migrations must be **side-effect-free / rollback-safe**. `193.ts` (SnapController → StorageService) uses `Promise.all` with no rollback on partial failure; it only self-heals on re-run. Add an architectural test / lint that flags non-idempotent migration side effects.
- [ ] Guard against **low-free-space failure**: the SnapController migration re-copies ~8MB+ and loops for users near their storage limit. Detect the condition and route it into degraded-persistence handling (E7) rather than looping.

## Dependencies
- **Depends on:** E2 (classification), E0 (baseline for validation).

### References

_No response_