Build the storage-write and corruption baseline dashboard

What is this about?

#44812 and #44813 define the fields and sampling rules for this dashboard. E6, E7, and E10 own the separate startup-loss, degraded-persistence, and backup signals.

Goal

Show write volume by controller or controller group, idle writes, and corruption events by logical key family.

Open questions

• Where will these views live?
• Who will own the dashboard after E0 is complete?

Technical Details

The dashboard uses the event fields from #44812 and #44813. Startup-loss detection remains in #44258, degraded-persistence signals remain in #44259, and backup signals remain in #44311.

Acceptance Criteria

• The dashboard shows write volume by controller or group and the idle dimension.
• The dashboard shows corruption events by logical key family.
• The dashboard documents its sampling and known gaps.

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
• Write measurements: #44812
• Corruption-key results: #44813
• Startup-loss detection: #44258
• Degraded persistence: #44259
• Full backup: #44311

Start by reading issues #44812 and #44813 for the event fields and sampling rules, then review parent issue #44250 to understand the dashboard scope. Resolve where the views will live and who owns them before implementation. Done means the dashboard covers write volume, idle writes, corruption by logical key family, and documents sampling and known gaps.