Follow-up to #2669, which made the guest drawer's filesystem rows follow
a linked Pulse agent's freshness. The workload table's disk cell and the
drawer History still judged the same guest by the Proxmox read reason,
so one guest disagreed with itself across the three.
## What changes
- **One rule for three readers.** `getWorkloadGuestDiskRead`
(`workloadGuestPresentation.ts`) now drives the table disk cell, the
drawer's filesystem rows and History. When the linked agent's
filesystems fill in for a VM that has no Proxmox guest filesystems, the
reading is current while the agent reports, last known once it is stale,
and unavailable once the guest is stopped. Proxmox's own guest
filesystems keep their read reason.
- **Where the aggregate disk metric comes from.** On a manually linked
VM, Proxmox records no guest disk usage without guest filesystems, so
the registry's link merge keeps the agent's disk metric. A registry test
pins that.
- **Poller carry-forward.** `previousVMFromView` built the previous VM
from the merged metric, so the next poll carried the agent's disk
forward as a Proxmox `prev-agent-not-running` read. Proxmox priority
then froze it over the agent's live value. Only Proxmox's own disk
reading is carried now (`VMView.DiskFromLinkedAgent`).
- **`agent.stale` is always on the wire.** The browser merges agent
facets field by field, so an omitted false kept a resumed agent "stopped
reporting" until a reload. This affected Machines rows and node drawers
too.
- **Withdrawn filesystems.** The websocket merge kept filesystems that a
native Proxmox VM facet or a native agent facet (which always carries
`stale`) no longer reported, including in the `platformData.agent`
mirror that host threshold rows read.
## Verification
- New tests, each failing on main: `GuestRow.test.tsx`,
`GuestDrawer.test.tsx`, `workloadGuestPresentation.test.ts`,
`resourceStateAdapters.test.ts`,
`TestPreviousVMFromViewKeepsLinkedAgentDiskOutOfProxmoxCarry`,
`TestAgentDataAlwaysSendsStale`,
`TestVMViewDiskFromLinkedAgentFollowsSelectedMetricSource`, and
`TestResourceRegistry_ManualGuestAgentLinkDiskMetricFollowsProxmoxGuestFilesystems`.
The registry test is a characterization test; it fails when the agent
outranks Proxmox on guest disk.
- Private mock stack at 1440 and 390, with agents linked into VMs
through `POST /api/resources/{vm}/link`:
- Live agent, no QEMU guest agent: before, "- Unavailable · Guest agent
not running", with History deferred; after, the agent's bars, nothing
deferred.
- Silent agent: before, "- Unavailable"; after, bars plus "Last known"
(phone: "Prior"), with History deferred on the agent message.
- Stopped guest: Unavailable.
- A guest with Proxmox filesystems: unchanged.
- Machines row for a standalone agent released from a silent hold,
watched without a reload: on main it kept "(stale)"; now it clears.
- Bundle: WorkloadsSurface 61.93 kB gzip against a 70.23 kB cap.
## Known residuals
- Mock mode's websocket state does not apply manual links to resources
ingested as records (`ingestRecords` never runs `applyManualLinks`), so
the browser pass ran the Proxmox page on REST data. In production this
likely affects links to vSphere or TrueNAS resources; it is tracked
separately.
- A stale Proxmox source can lose the aggregate to a live agent while
its own filesystem rows and `prev-` reason remain. That guest stays on
the Proxmox rule and reads its live aggregate as last known, which is
the same as main and errs toward caution. A guest with no platform read
reason can likewise keep a retained aggregate after the agent withdraws
its filesystems, also as on main. Both need aggregate provenance on the
wire.
rcourtman
6263c580f7