Say why vSphere datastores and networks need attention

An amber vSphere datastore or network gave no reason on its row: the
vCenter alarm behind it sat one click away in the drawer or one tab
away on the Overview. The alarm text itself led with boilerplate
("Network network-302 has VMware alarm ... (yellow)"), so the Overview
truncated the part that mattered.

A vCenter incident summary is now what vCenter flagged: the alarm's
own name, or "vCenter health is <colour>". Every surface that shows
it already names the resource and severity. Alert cards, notification
templates, and Patrol titles carry the resource name. Patrol's seed
context now names the resource on each alert line, and Patrol titles
key off the incident code instead of parsing the wording, while still
reading records persisted in the old form.

The alert card used to find vSphere by looking for "vmware" in the
message. It now routes on the incident provider, which also sends ESXi
host alarms to vSphere instead of to Machines, where hosts are not
listed. The card's own test becomes a registered alerts proof.

The Datastores and Networks tables gain the exception-first Health
column that TrueNAS storage uses. The cell moves into a shared
PlatformIssueReason, so the two platforms cannot drift; TrueNAS
renders the same. A row's dot and its reason now come from one
classification. Hosts shows only from a 72rem container, where it
reads instead of truncating, and the tablet band splits columns by
weight.

docs/release-control/v6/internal/subsystems/ai-runtime.md

@@ -4629,7 +4629,16 @@ titles: provider alarm messages yield their bounded alarm subject, generic
 resource/storage incident types become plain issue language, and known
 acronyms such as CPU, ZFS, and I/O retain their canonical casing. Clients must
 not receive machine-title-cased placeholders such as `Resource Incident` and
-repair them independently. The projection also collapses open/resolved churn:
+repair them independently. VMware incidents are recognized by the alert's
+`incidentCode` metadata, never by parsing message wording: a
+`vmware_alarm_state` alert is titled with the alarm name its message carries,
+cut before any appended consumer summary, and a `vmware_health_state` alert
+reads as VMware host or datastore health. Records persisted before VMware
+summaries became the alarm name still carry "<entity> <moref> has VMware alarm
+<name> (<colour>)", so the title strips that wording to the same alarm name.
+Patrol's seed context lists active and recently resolved alerts by resource:
+each line names the alert's resource unless the message already does, because
+provider incidents such as vCenter alarms say only what was flagged. The projection also collapses open/resolved churn:
 when a record's timeline holds at least four open-to-resolved or
 resolved-to-open transitions inside the last 24 hours, the item carries a
 `flapping` summary (transition count, window, first and latest transition) and

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

@@ -2431,6 +2431,12 @@ mapping. Acknowledged cards keep their canonical badge and omit that redundant
 line; held delivery states that can surprise an operator use the attention
 tone, while cooldown, quiet-hours, monitor-only, and successful/pending states
 remain neutral.
+The card's resource link resolves the owning platform page from alert
+metadata, never from message wording alone: a provider incident whose
+`incidentProvider` is `vmware` links to the vSphere overview even though its
+message is only the alarm vCenter raised, and VMware incidents land on
+canonical `vm`, `storage`, `network`, and `agent` resource types rather than a
+`vmware-` prefixed type.
 The retired dashboard recent-alert panel must not be reintroduced as a
 parallel alert surface. Alert summary/tone copy belongs to the alert overview
 presentation owner, and any future compact alert surface must compose the

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

@@ -2041,6 +2041,16 @@ deck or VMware-local page shell. Its rows are canonical `network` resources in
 the shared reportable/resource vocabulary, so source badges, resource pickers,
 command-palette search, table chrome, and detail disclosure must all consume
 shared primitives before VMware-specific presentation logic.
+A platform table's Health column, which says why a row's status dot is not
+green, renders through `PlatformIssueReason`
+(`frontend-modern/src/features/platformPage/PlatformIssueReason.tsx`): the
+first reason on the row's single line in the tone's colour, a count for the
+rest, every reason in the title and screen-reader text, and an empty cell for
+a healthy row. TrueNAS storage and the vSphere Datastores and Networks tables
+consume it, and the column stays desktop-only on each of them; a platform
+table must not hand-roll its own reason cell. On vSphere Datastores and
+Networks the Hosts list shows only from a 72rem container, where it reads
+instead of truncating, and the drawer keeps it at every width.
 Patrol's primary assessment strip is descriptive only; it must not render a
 Patrol-authored recommended next step, suggested prompt chips, or a secondary
 action band inside the assessment shell. If the same assessment opens

docs/release-control/v6/internal/subsystems/registry.json

@@ -2599,6 +2599,7 @@
               "frontend-modern/src/features/alerts/__tests__/AlertDeadManDestinationSection.test.tsx",
               "frontend-modern/src/features/alerts/__tests__/AlertIncidentSynthesisSummary.test.tsx",
               "frontend-modern/src/features/alerts/__tests__/AlertIntentPolicyPanel.test.tsx",
+              "frontend-modern/src/features/alerts/__tests__/AlertOverviewAlertCard.system-scope.test.tsx",
               "frontend-modern/src/features/alerts/__tests__/alertsConfigurationModel.test.ts",
               "frontend-modern/src/features/alerts/__tests__/helpers.test.ts",
               "frontend-modern/src/features/alerts/__tests__/OverviewTab.emptystate.test.tsx",

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

@@ -1095,6 +1095,17 @@ The first reason renders in the desktop Health column on the row's single line,
 coloured by bucket, with a count for the rest and the full list in the title
 and screen-reader text. Phones keep the status dot and reach the reason through
 the row drawer. Health sorts by severity rank, not label text.
+The vSphere Datastores and Networks tables follow the same exception-first
+Health column. `getVmwareDatastoreIssue` and `getVmwareNetworkIssue` return
+nothing for a green row; otherwise the reasons are, in order, an impaired
+vCenter source, a datastore's inaccessible or maintenance state, the
+resource's incident summaries worst first, and, only when no incident explains
+the colour, vCenter's overall status or its active alarm count. Inaccessible,
+offline, red, or critical rows take the red tone. VMware incident summaries say
+only what vCenter flagged, the alarm's own name or `vCenter health is
+<colour>`, without the managed object ID or alarm colour: every surface that
+shows them (alert cards, notifications, the Overview and Health signal tables,
+the drawer, Patrol titles) already names the resource and its severity.
 That shell also owns responsive width composition. Source tables may declare
 desktop breakpoint floors, but the phone branch must fit its selected columns
 inside the available container without a horizontal rail. Each unified-resource