Storage Resilience E0: Instrumentation Baseline

Nobody has claimed this yet.

### What is this about?

E0 supplies the measurement baseline needed by the other storage-resilience issues: per-write size, frequency, controller attribution, and idle status, plus logical-key results when corruption is detected.

## Goal

Land per-write size, frequency, originating-controller, and idle telemetry; capture readable, corrupted, and missing logical keys when corruption is detected; and build the baseline dashboard.

## Tasks

- [ ] [Land controller write-frequency + size instrumentation](https://github.com/MetaMask/metamask-extension/issues/44812) from PRs #44174, #44175, #44176, #44177, #44178, and #44179. Sample on write to bound the `JSON.stringify` cost.
- [ ] [Tag each write with `is-idle` + originating controller](https://github.com/MetaMask/metamask-extension/issues/44812). Use the idle definition from #44800.
- [ ] [Capture corrupted, readable, and missing keys on corruption](https://github.com/MetaMask/metamask-extension/issues/44813); add a `corrupted-keys` field to the recovery telemetry event.
- [ ] [Stand up the baseline Sentry dashboard](https://github.com/MetaMask/metamask-extension/issues/44814): write volume by controller and group; corruption events by key family.

## Scope

The current split-state path receives `controllerKey` before persistence is debounced, and `PersistenceManager` retains the pending controller keys. PRs #44174 through #44179 explore the write and read diagnostics. Size measurement must be sampled because it serializes state, and telemetry must contain no state values. The old full-state persistence path is out of scope.

- **Add the write measurements.** Record write size, frequency, contributing controllers, and whether MetaMask was idle. Sample serialization as required by E0.
- **Represent batching correctly.** Keep every controller included in a debounced persistence write.
- **Capture corruption results.** Report which logical keys were readable, corrupted, or missing without including their values.
- **Build the baseline dashboard.** Show write volume by controller or group and corruption by key family.

## Linked issues

- [#44812: Measure persistence write size, frequency, controller, and idle status](https://github.com/MetaMask/metamask-extension/issues/44812)
- [#44813: Report logical-key read results when corruption is detected](https://github.com/MetaMask/metamask-extension/issues/44813)
- [#44814: Build the storage-write and corruption baseline dashboard](https://github.com/MetaMask/metamask-extension/issues/44814)
- [#44800: Define the idle heuristic used by persistence telemetry](https://github.com/MetaMask/metamask-extension/issues/44800)

## Open questions

- Which event should own each write measurement?
- How often must write size be sampled to be useful without adding significant overhead?
- How will corruption diagnostics report logical-key outcomes without including persisted values?

### Scenario

_No response_

### Design

_No response_

### Technical Details

The performance initiatives overlap on write size, frequency, and controller attribution. Collect that extension-side data once where practical. Startup timing, controller-initialization timing, and persistence duration remain part of the performance work.

#44322 may supply controller attribution, but E0 does not need to wait for it. Missing-key detection, capacity handling, migrations, recovery, and backups remain in their own issues.

### Threat Modeling Framework

_No response_

### Acceptance Criteria

- [ ] Per-write telemetry records size, frequency, originating controller, and idle status.
- [ ] Corruption diagnostics identify readable, corrupted, and missing logical keys without including their values.
- [ ] The baseline Sentry dashboard shows write volume by controller or group and corruption by key family.
- [ ] The instrumentation has acceptable overhead.

### 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

- Parent epic: #44248
- [MetaMask-planning #6730: Metrics Collection Expansion](https://github.com/MetaMask/MetaMask-planning/issues/6730)
- [MetaMask-planning #7473: State I/O Instrumentation](https://github.com/MetaMask/MetaMask-planning/issues/7473)
- [MetaMask-planning #7362: State-write size and frequency](https://github.com/MetaMask/MetaMask-planning/issues/7362)
- [MetaMask-planning #6749: Persistence I/O duration](https://github.com/MetaMask/MetaMask-planning/issues/6749)
- [MetaMask-planning #6747: Background Load Metrics](https://github.com/MetaMask/MetaMask-planning/issues/6747)
- [MetaMask-planning #6751: Controller Init Breakdown](https://github.com/MetaMask/MetaMask-planning/issues/6751)
- #44322: possible shared controller registry and event source
- Exploratory PRs: #44058, #44174, #44175, #44176, #44177, #44178, and #44179

The linked PRs are exploratory. Linking them here does not select an implementation.

Start by tracing the split-state path and PersistenceManager, then review exploratory PRs #44174–#44179 and the linked issues #44812–#44814. The work is done when sampled write telemetry includes the required attribution and idle fields, corruption reports logical-key outcomes without values, and the baseline Sentry dashboard shows the specified groupings with acceptable overhead.

Written by the indexing model from the issue text.