feat: Windows is not an OS grid this product serves

[kelvin1295]

Removes windows from the closed OS-token set. Windows is not an operating system this product serves an OS grid for.

A Windows machine now takes the branch a BSD takes: no token, no os= on the wire, and D-k's unsupported_system sentence naming the set it is outside of — which is more actionable than not_served, since that one invites waiting for a deployment that is never coming.

The control-plane half is autonomous-ai/autonomous-grid-be@9f384ed, already on that repo's main.

system	before	after
Windows	os=windows → the Windows grid	no os= at all → "No OS grid for Windows: grid has one only for macos, linux and omarchy"
macOS / Linux / Omarchy	unchanged	unchanged

⚠️ The one token this set has ever LOST rather than never had

Every other absence in ADR 0039 is one nobody has to remember — other, FreeBSD, a frozen build naming no system. windows is different: platform.system() obviously knows about it, host.platform_kind() still carries it (a build target is not a community), and every map in this feature looks incomplete without it.

So the removal is stated where somebody editing the map will read it — os_grid._BY_SYSTEM, os_networks.DEFAULT_SERVED_OS_TOKENS, _OS_LABELS — and pinned by a test that asserts the absence. No parametrize can fail for a row that is simply no longer there.

⚠️ Removing the token does NOT stop an existing Windows grid serving

The code cannot do that half. The served list is consulted only by ensure_pending_os_network, so it governs creation; admission is grid-apis store.os_gate_for, which compares a request's claim against the row's own access_os and never consults it.

So a CLI old enough to still claim windows — v0.3.29 and earlier — keeps being admitted to a windows grid that is still active. Retiring the OS needs the grid taken out of service too, which is exactly what os_grids_enabled's docstring already said: "drop its token … and stop the grid".

Measured today: PROD has no Windows grid; the dev VM has one, and it is being taken down alongside this change.

Three tests lost their MEANING, not a line — rewritten rather than deleted

• is_served_os_token("windows") is False under an explicit GRID_OS_GRID_TOKENS: with windows gone from the default this reads False whether the explicit list is honoured or ignored, so it proved nothing. The excluded token now has to be one the default does serve — omarchy.
• The GRID_OS_GRID_ENABLED-off test asked for os=windows, so [] would have had two causes at once and the test stopped isolating the switch. It asks for linux.
• The soft-delete re-claim test seeded a windows grid. The store never consults the served list so it passed either way, but the vocabulary would have told the next reader that Windows is supported.

Also fixed here

A latent version of the hazard the omarchy PR named: _absence and _refresh_body did not stub _OS_RELEASE, so their Linux cases were statements about whatever host ran the suite rather than about the code.

Rollout

No ordering in either direction, and that is a change from the omarchy PR: removing a token is a narrowing. A Windows machine loses its grid when its own CLI upgrades, not when the control plane deploys; and the grid stays reachable for old CLIs until it is stopped, whichever side ships first.

Test plan

• pytest tests/ — 0 failures (re-run after merging main)
• grid-apis pytest tests/ — 1157 passed, 0 failed
• ruff — no new findings (98 on the changed files at HEAD, 98 after; the repo-wide 483 is pre-existing baseline)
• Cross-repo lockstep run locally with the sibling worktrees present (it skips in CI)
• PROD and dev both inspected for existing windows grids

🤖 Generated with Claude Code

https://claude.ai/code/session_01HXNAadpsFfETXENbie3p91