docs: Describe the Windows agent's update and workload support

CLAUDE.md

@@ -315,6 +315,17 @@ a Service cannot address the one pod holding a console listener.
 
 Agents report CPU/memory/swap/partitions/kernel — metrics every 30s, full static snapshot every 15 min. They also check for pending OS package updates hourly and can apply them on command (`ApplyUpdatesCmd`).
 
+Windows update checking and applying go through the Windows Update COM API
+(`Microsoft.Update.Session`) rather than the PSWindowsUpdate module, which would
+need a PowerShell Gallery install on every host and fails on an air-gapped
+fleet. `CurrentVersion` is empty on Windows and `NewVersion` carries the KB
+article ID: a Windows update is not a version bump of a named package.
+
+**The agent never reboots a host.** `ApplyUpdatesCmd` installs and stops there;
+`inventory.reboot_required` reports that one is owed, set on the static snapshot
+every 15 minutes. Linux fills it too, from `/var/run/reboot-required` or
+`dnf needs-restarting -r`.
+
 ### Package inventory and CVE findings
 
 Agents report their installed packages hourly; the control plane matches them
@@ -364,10 +375,22 @@ scheduler off entirely.
 
 A **workload** is one Docker container or one systemd unit — one word for the
 page, the collection and the commands, rather than saying "container or
-service" in every identifier. Linux only, and **not gated by licence**: this
-reads as core fleet management, so v1 ships everywhere with no `HasFeature`
-check. If that changes the check belongs at `ReportWorkloads`, gating collection
-rather than display, exactly as sub-project A does.
+service" in every identifier.
+
+On Windows a workload is a Docker container or a Windows **service**, reported
+under the same `unit` kind and the same `systemd_ok` / `systemd_error` fields —
+one wire shape, worded per platform in the UI, which is the only layer that
+knows the host's OS. The platform split lives entirely in the agent, as build
+tags (`systemd_linux.go` / `services_windows.go` and the matching `control_`
+and `logs_` pairs); the control plane is OS-blind and needed no changes.
+Windows collection runs PowerShell through `agent/internal/winexec`, and every
+script emits JSON that a build-tag-free parser reads, so the parsers are tested
+on Linux — the agent module has no Windows CI.
+
+**Not gated by licence**: this reads as core fleet management, so v1 ships
+everywhere with no `HasFeature` check. If that changes the check belongs at
+`ReportWorkloads`, gating collection rather than display, exactly as sub-project
+A does.
 
 Agents collect on a 60-second ticker and report through `ReportWorkloads` with
 the **offer-then-send** handshake the package report already uses. The offer is
@@ -391,8 +414,9 @@ reads get `WorkloadLogsResult`. `CommandStream` republishes **every**
 no-op, so this costs nothing and avoids a second result path.
 
 **The protected set is computed agent-side and enforced agent-side.**
-`vantage-agent.service`, plus the container ID read from `/proc/self/cgroup`
-should the agent ever run in a container. As with the console relay hardcoding
+`vantage-agent.service` on Linux, `VantageAgent` on Windows, plus the container
+ID read from `/proc/self/cgroup` should the agent ever run in a container. As
+with the console relay hardcoding
 `127.0.0.1`, the control plane may name a target but the agent decides what it
 will do to itself; a server-side denylist alone would be bypassed by the next
 dispatch path someone adds, and the failure is unrecoverable from the UI. The
@@ -1144,7 +1168,12 @@ git push origin main                                    # server + web deploy
 - **guacd for console** — protocol handling is Guacamole's problem, not ours; we proxy the WebSocket and manage credentials.
 - **`org_id` on every document** — isolation enforced at the query layer, not by separate databases.
 - **root only** — manages `/root/.ssh/authorized_keys`; no per-user key management.
-- **Windows agents are second-class by design** — register, heartbeat, run steps, report inventory; no `authorized_keys` management.
+- **Windows agents cover the fleet-management path** — register, heartbeat, run
+  steps, report inventory, OS updates through the Windows Update COM API, and
+  workloads (services plus containers, with control and logs). They still do no
+  `authorized_keys` management, and no package inventory or CVE matching: the
+  vulnerability feeds this project uses carry no Windows data, so a Windows host
+  correctly reports `unsupported` rather than a clean bill of health.
 - **Both `server` and `web` scale horizontally** — see "Running more than one server replica" below. `web` holds nothing; `server` holds per-agent state that is routed between replicas over Redis rather than duplicated.
 - **Deletion lives in the control plane** — admin sends the warnings because it knows the billing address; the control plane performs the delete because it is the only service that knows which collections carry `instance_id`. Mirroring that list into admin would drift, and a drift there deletes the wrong rows.