Report logical-key read results when corruption is detected

**What is this about?**

`ExtensionStore` reads the split-state manifest, then requests the listed controller keys. Current recovery telemetry describes the vault-level result. PRs #44178 and #44179 explore per-key reads and attach the results to the corruption event.

## Goal

Report which logical keys were readable, missing, or failed to read when the corruption path runs.

## Open questions

- Which per-key outcomes can the storage API distinguish reliably?
- How should several affected keys be represented on one event?

**Technical Details**

E6 #44258 owns the separate startup check for missing expected controller keys.

**Acceptance Criteria**

- [ ] The corruption event includes the logical key and read result for each relevant key.
- [ ] Telemetry contains no stored values or nested controller fields.
- [ ] Tests cover readable, missing, and failed key reads.

**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: #44250
- Startup missing-key detection: #44258
- Exploratory PRs: #44178 and #44179

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

Start at ExtensionStore’s split-state manifest read and the corruption event, then review exploratory PRs #44178 and #44179 to understand the per-key read results. Confirm the storage API’s readable, missing, and failed outcomes, keeping values and nested controller fields out of telemetry. Add coverage for those outcomes and verify each relevant logical key appears in the event.

Written by the indexing model from the issue text.