Cut time sync collection, pin Windows Update history

w32time is Stopped on provisioned endpoints, confirmed on more than one box, so w32tm returns 0x80070426 fleet-wide and there is no offset to read. It appears to be stopped by policy after provisioning. Collecting it would return null everywhere and give us an alerting signal that can never fire, which is worse than not having one: a permanently-null health check reads as no problem found.

Implemented first, then removed - collector, both parsers, the process helper, and the contract field. Kept one note in the notes file: parse the offset by label, not by first value ending in s, because w32tm prints Root Delay and Root Dispersion in the same format beforehand and a first-match parser reports network latency as clock skew. That bug was written and caught here.

Windows Update history is pinned rather than cut. The COM update searcher is slow, but the blocking concern is that some endpoints host COM server applications where driving it risks interfering with collections or the hosted application. Needs its own investigation. The Phase 4 card that depended on it is marked blocked so the two do not drift apart.

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

@@ -120,9 +120,22 @@ above an elevated remap has the same problem).
 All service-side, no session needed. Group these because they share the
 inventory-snapshot plumbing and one migration.
 
-- **Time sync offset and source** - collect; NOT surfaced in the UI. Wire for
-  alerting only. Kerberos fails past skew, so this is a high-value silent
-  predictor.
+- **Time sync offset and source** - CUT. Do not collect, do not surface.
+  w32time is Stopped on provisioned endpoints, confirmed on more than one box
+  (`get-service w32time` -> Stopped). The service appears to be stopped by
+  server-side policy after provisioning, so `w32tm /query /status` returns
+  0x80070426 "service has not been started" fleet-wide and there is no offset to
+  read. Collecting it would return null everywhere and produce an alerting
+  signal that never fires - worse than nothing, because a permanently-null
+  health check reads as "no problem found".
+
+  Implemented and then removed in this phase. If time skew becomes a real
+  suspect later, the prerequisite is getting w32time RUNNING on the fleet; the
+  collection is the easy part. One implementation note worth keeping: parse the
+  offset by LABEL, not by "first value ending in s". w32tm prints Root Delay and
+  Root Dispersion in the same seconds format BEFORE Phase Offset, so a
+  first-match parser silently reports network latency as clock skew. That bug
+  was written and caught here; do not rewrite it.
 - **Disk errors / SMART predictive failure** - collect and surface on the
   existing Storage card (Phase 4).
 - **NIC link speed and duplex** - collect, pair into the existing Network
@@ -130,9 +143,16 @@ inventory-snapshot plumbing and one migration.
 - **Boot type** - fast startup vs true cold boot. Explains why uptime lies and
   why a "reboot" did not clear a fault. Collect now; UI placement undecided,
   candidate for the Operating system or Hardware card.
-- **Windows Update history, last 5** - surfaced in Monitors (Phase 4) for
-  pinpointing update-induced breakage. Updates are corporate-managed; this is
-  diagnostic only, not control.
+- **Windows Update history, last 5** - PINNED, deferred out of Phase 2. The COM
+  update searcher is not cheap: it routinely takes seconds and sometimes tens of
+  seconds, which would make it the most expensive thing in an otherwise
+  WMI-and-registry `Collect()` running on the heartbeat path.
+
+  The blocking concern is broader than cost. Some endpoints host COM server
+  applications, and driving the update searcher through COM on those boxes risks
+  interfering with collections - or with the hosted application itself. Needs
+  its own investigation before any implementation, and if it lands it wants its
+  own cadence (hourly/daily), never the every-cycle path.
 - **Defender/AV health** - collect and persist, do NOT surface. Known to
   produce false positives in this environment; stored for future wiring.
 
@@ -181,7 +201,9 @@ Depends on Phase 2 data existing.
   new CSS. Room reserved for the future one-click fix action.
 - **Storage card** - add disk error / SMART predictive failure to the existing
   card rather than a new one.
-- **Windows Update card** - last 5 updates, in the System Monitors tab.
+- **Windows Update card** - BLOCKED, not scheduled. Depends on Phase 2 data
+  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.
 
 ## Phase 5 - Header right-hand block (DEFERRED - revisit before building)