feat(monitoring): promote GPU load to first-class metrics

docs/release-control/v6/internal/subsystems/agent-lifecycle.md

@@ -1493,9 +1493,12 @@ the intentionally sparse public response.
    query as a best-effort fallback when `lm-sensors` is unavailable. The report
    must keep typed GPU readings in `sensors.gpu` while mapping only direct
    `temperature.gpu` readings into existing `sensors.temperatureCelsius`
-   `gpu_nvidia_<index>` keys for compatibility; it must not infer lifecycle
-   health, command authority, enrollment state, or GPU workload/process
-   inventory from `nvidia-smi` output.
+   `gpu_nvidia_<index>` keys for compatibility. Authenticated server ingest may
+   reduce those typed samples into bounded host-level GPU utilization, VRAM
+   pressure, and GPU temperature history on the existing agent identity, but
+   that monitoring projection does not change the report or command protocol.
+   Neither side may infer lifecycle health, command authority, enrollment
+   state, or GPU workload/process inventory from `nvidia-smi` output.
    Runtime RAID collection uses `/proc/mdstat` as the canonical discovery
    baseline for Linux md arrays. `mdadm --detail` may enrich level, state,
    member, UUID, and rebuild fields when available, but missing or failing

docs/release-control/v6/internal/subsystems/frontend-primitives.md

@@ -5530,3 +5530,21 @@ renders the canonical dataset name and formatted used, available, referenced,
 and mountpoint values. Empty dataset collections add no new panel, route, or
 navigation state. The presentation mapper owns byte formatting and missing
 mountpoint fallback so components do not reinterpret provider data.
+
+### Host GPU telemetry reuses shared metric and history primitives
+
+The standalone machine table may expose typed host GPU utilization as a
+toggleable, sortable `metric-bar` column, but it must render through the shared
+`MetricBar` primitive and use the unified resource's existing metric key. The
+row model owns validation, maximum-per-host selection, and the per-device
+inspection title; the component must not invent vendor-specific probes or a
+parallel GPU table.
+
+The shared resource drawer keeps `GuestDrawerHistory` as the sole history
+renderer. Resources with typed GPU sensors may extend its normal groups with
+core utilization, VRAM pressure, and GPU temperature series and provide current
+typed readings as initial fallbacks. Resources without GPU sensors retain the
+default history groups unchanged. Rendered table proof belongs in
+`frontend-modern/src/features/standalone/__tests__/AgentsMachinesTable.test.tsx`;
+drawer grouping and fallback proof belongs in
+`frontend-modern/src/components/Infrastructure/__tests__/resourceDetailDrawerMetricsHistoryModel.branchcov0712.test.ts`.

docs/release-control/v6/internal/subsystems/monitoring.md

@@ -1270,9 +1270,15 @@ exists.
 Host-agent GPU sensor summaries follow that same descriptive-host-telemetry
 path. Monitoring must preserve typed GPU id, name, temperature, utilization,
 and VRAM readings from agent reports through models, read-state projection, and
-frontend conversion, while still using only real Celsius readings for
-`agent.temperature` or `metric=temperature` and without promoting GPU workload
-or process inventory into monitoring state.
+frontend conversion. When typed readings are present, authenticated host-report
+ingest records bounded maximum-per-host `gpu`, `gpu_memory`, and
+`gpu_temperature` samples in both in-memory guest history and the persisted
+`agent` metrics-store stream. Utilization and VRAM pressure are percentages;
+VRAM pressure is derived only from non-negative used bytes and a positive total,
+and temperatures must be positive Celsius values no greater than 150. Missing
+or invalid fields omit only their own series. The aggregate remains attached to
+the existing agent resource and does not promote GPU workload or process
+inventory into monitoring state.
 Host-agent power sensor summaries follow the same descriptive-host-telemetry
 path. Monitoring must preserve `sensors.powerWatts` readings from agent reports
 through models, read-state projection, and frontend conversion without

docs/release-control/v6/internal/subsystems/unified-resources.md

@@ -464,9 +464,13 @@ history target.
 Typed GPU host telemetry follows the same canonical sensor route.
 `HostSensorMeta.gpu` may carry GPU id, name, temperature, utilization, and VRAM
 readings through clone, merge, transport, and frontend decode paths, but those
-readings remain descriptive host context. Unified-resource consumers must not
-promote GPU sensors into separate hardware resources, lifecycle state, workload
-identity, or history targets beyond direct numeric temperature compatibility.
+readings remain descriptive host context. Standalone machine consumers may
+present the maximum valid utilization as a sortable shared metric-bar column,
+include per-device utilization, VRAM, and temperature in inspection text, and
+add `gpu`, `gpu_memory`, and `gpu_temperature` series to the existing agent
+drawer history target. Those projections must stay on the host resource;
+consumers must not promote GPU sensors into separate hardware resources,
+lifecycle state, workload identity, or GPU-specific history identities.
 Host-agent wattage follows that same canonical sensor route.
 `HostSensorMeta.powerWatts` may carry named power readings through clone,
 merge, transport, and frontend decode paths, but those readings remain