Flag an outdated agent once on the Infrastructure page (#2531)

Each outdated Pulse Agent on Settings › Infrastructure was flagged
twice: an amber **Agent update** badge, plus a second-line **Version
behind** note. The band also counted every outdated agent as needing
attention. On a mock estate it read "11 systems needs attention", and
all 11 were version lag.

- **Version lag is maintenance.** Version behind and Update available
are now maintenance signals. The badge, which opens Agent Doctor,
carries them, so they never become the row's problem line and don't
count toward needs attention. The Manage drawer still lists every fleet
signal.
- **Real update problems still show.** A failed update and auto-update
switched off remain row problems, since each needs a different action.
- **Problems can't hide behind the cap.** A row's problem is now picked
from all its visible signals before the three-highlight cap, and
problems rank ahead of maintenance. A second attached agent's failed
update can no longer fall behind another agent's version lag.
- **The band** says how many agent updates are available, in a neutral
tone. "Systems need" and "hosts have" now agree in number.
- **Column widths.** The Actions column is wide only when a row shows an
install button beside Manage, and Health gets 27% of the table. The
Health cell now keeps the status, the badge and the last-seen time on
one line. On main, the last-seen time was cut to "18s a…".

Verification:
- At 1280, 1440 and 1920px the table has 16 rows and no clipped cells.
Main has 27 rows (including 11 problem lines), with 11 and 6 clipped
cells at 1280 and 1440px.
- The phone card layout shows no Version behind lines.
- Re-measured after rebasing onto the shared Table change in #2524. The
receipt is included.

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

@@ -5127,6 +5127,20 @@ API and Pulse Agent`) from the shared ledger contract. The compact landing may
 render its API / Agent / API + Agent badge beside the system name, with the full
 phrase available through accessible metadata and the detail flow, instead of
 spending a separate table column on collection method.
+An agent that is behind the Pulse Agent target or has an update waiting is
+maintenance, not a problem: the row's `Agent update` badge says so once and
+opens Agent Doctor, so `primaryRowProblem` skips signals marked `maintenance`
+(Version behind, Update available) and the row adds no `Version behind` line
+beneath itself. Those rows therefore do not count toward the band's `needs
+attention` total, which counts them separately and neutrally as agent updates
+available. A failed update and auto-update switched off remain row problems,
+because each asks for a different action, and the Manage drawer still lists
+every fleet signal. A row's problem is picked from all of its visible signals
+before the three-highlight cap, and problems rank ahead of maintenance in that
+list, so a second attached agent's failed update cannot fall behind another
+agent's version lag. The Actions column is only as wide as an install button
+beside Manage needs when a row in view shows one, so Health keeps its state,
+the update badge and the last-seen time on one line.
 Source badge class selection may use semantic gray treatment for API-only rows
 and typed non-gray tones for agent, probe, or combined sources, but the source
 identity remains the API/Agent/Probe label and subtitle from the shared ledger

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -7343,6 +7343,11 @@ agent-applied setting, `fleet.configDrift` must remain `not-applicable` and
 diagnostics, but must not count that passive state as source setup attention.
 Only a real managed desired config fingerprint can create pending rollout
 attention when an applied fingerprint is absent or mismatched.
+Likewise `fleet.versionDrift: behind` and `fleet.updateStatus:
+update-available` are maintenance, not source setup attention:
+`useConnectionsLedger.ts` keeps them out of a row's problem and the band's
+needs-attention count, which the row's agent-update count and badge carry
+instead, while `updateStatus: failed` and `disabled` remain row problems.
 The `fleet.commandPolicy` object is the canonical desired/applied convergence
 contract for remote command enablement. It must carry the desired server
 policy, the applied agent-reported truth when available, the effective

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

@@ -2633,7 +2633,9 @@ Agent`), with the plain-language source phrase available through accessible
    always-on version column for Pulse Agent; exact version text belongs in the
    edit/detail surfaces, while the landing table only surfaces a compact
    warning badge when an attached or standalone agent actually has an update
-   available. That same table boundary must reuse the `System` cell for compact
+   available. That badge is the row's only version flag: the row adds no
+   `Version behind` problem line beneath it, and the source band counts those
+   rows as agent updates available rather than as needing attention. That same table boundary must reuse the `System` cell for compact
    standalone-agent identity such as `Unraid 7.1.0`; raw reported addresses
    belong in the governed Manage detail or an explicitly expanded
    cluster-member row, not an always-on diagnostics column.