Scope the Storage and Disk health grouping

Records the agreed plan to combine the two cards into one with two collapsible sections, as VISUAL GROUPING ONLY. The two tables cannot share rows: Storage is per volume, Disk health is per physical device, and one drive can back several volumes or none the operator sees. Stating that explicitly so this is never mistaken for the Phase 1 mapped-drive merge, where two sources described the same drive and the worse status won.

Deferred to its own phase because the tabs render type emits label/value fields only and has no table path, so this means extending the renderer every plugin uses. Bundling that with the Phase 2 telemetry work would turn a UI regression and a telemetry regression into one commit to bisect.

Also scopes the not nested cards density rule to the header block it was written for, having checked it does not block this.

docs/notes/endpoint-telemetry-and-ui-phases.md

@@ -226,6 +226,30 @@ Depends on Phase 2 data existing.
   that is pinned pending a COM-interference investigation. Do not build the card
   until the collection question is settled.
 - Boot type placement to be decided when the data is visible.
+- **Storage + Disk health into one card with two collapsible sections** -
+  AGREED, deferred to its own phase. VISUAL GROUPING ONLY. These two tables
+  cannot be merged into shared rows: Storage is per volume, Disk health is per
+  physical device, and one drive can back several volumes or none the operator
+  sees. This is emphatically NOT the Phase 1 mapped-drive treatment, where two
+  sources described the same drive and the worse status won. Nothing here gets
+  reconciled.
+  Cost, measured rather than guessed: the `tabs` render type is the only
+  existing sections-in-one-card mechanism and it emits label/value fields only
+  (PluginAssetPanels.vue), with no table path. Both cards here are `table`
+  renders with different columns AND different keys, so nothing existing
+  carries them. Preferred approach is extending `tabs` to support table
+  sections (~40 lines in the shared renderer plus a helper), then collapsing
+  the two routes into one returning `sections`. A new `sections` render type is
+  the alternative but is a larger addition to that fixed set.
+  Deferred deliberately: this modifies the renderer EVERY plugin uses, so it
+  needs its own regression tests and must not be bundled with the Phase 2
+  telemetry commits - otherwise a UI regression and a telemetry regression
+  become one commit to bisect.
+  Checked and cleared: the "inline label/value pairs, not nested cards" density
+  rule in Phase 5 does NOT block this. That rule is scoped to the PC Details
+  HEADER block, where the constraint is adding zero height so the tab strip is
+  not pushed toward the fold. It says nothing about panel bodies in the
+  Monitors tab.
 
 ## Phase 5 - Header right-hand block (DEFERRED - revisit before building)
 
@@ -263,6 +287,11 @@ Density rules if this proceeds: inline label/value pairs, not nested cards. Do
 not let the right block grow taller than the left identity block, or it starts
 adding height after all and the zero-cost property is lost.
 
+Scope note: that "not nested cards" rule is about THIS header block only, where
+the whole value is adding zero height. It is not a general ban on sections
+inside a panel body - the Phase 4 Storage + Disk health grouping was checked
+against it and is not blocked.
+
 Still true and still unbuilt if this proceeds:
 - `Collectors` is not a current tab or group. If IP History moves to a new tab,
   that is the same three-file atomic change as Phase 3.