test(windows): isolate the daemon guards' rendezvous and stop hiding their failures

[DeusData]

What

The Windows daemon guards shared one machine-global daemon, and their failure output hid why anything went red. This isolates test_daemon_stability.py per section via CBM_RUNTIME_DIR and makes every failure path print what actually happened.

Why — the false premise

test_daemon_stability.py documented that "each section runs under its OWN cache directory: daemon coordination is cache-scoped". It is not:

• the rendezvous key is FNV-1a over a compile-time domain string (service.c: cbm_daemon_rendezvous_key);
• the parent is win_default_runtime_parent() → SHGetFolderPathW(CSIDL_LOCAL_APPDATA), which ignores the LOCALAPPDATA variable (so even test_non_ascii_path.py's redirect does not relocate it);
• CBM_CACHE_DIR moves the cache, never the rendezvous (bootstrap.c says exactly this).

So the guard's own daemon stop / kill -9 sections, the sibling guards, and anything else on the runner met the same daemon, and a daemon wedged anywhere failed every check after it. That is the shape of this week's test-windows-guards red on #1874: lifecycle's daemon start connected, the UI-config handshake never answered, then stability / hook_augment / ui_drive / cli_non_ascii went red in a row with an orphan daemon killed at cleanup — on a diff and a base that were each green elsewhere.

CBM_RUNTIME_DIR is the only relocation hook (resolved in cbm_daemon_bootstrap_endpoint_new for every product endpoint). Each section now gets a private runtime parent next to its cache, created before the binary runs (the endpoint validates the parent and never creates it); the daemon inherits it from the client that spawns it.

The reporting fixes

Before	After
SETUP FAIL printed nothing	prints the daemon's full stdout+stderr
every RED printed a 300–400 char head slice (= the allocator preamble)	tail excerpt, 1500 chars
a timeout on a parallel-client thread was lost → rc=none, no output	kept as a failed result with partial output; a section-level timeout is a named RED with command + output
MCP session stderr → DEVNULL	→ file, printed when initialize never answers — and that is a RED against a running daemon, not a setup skip
exit 2 documented, never produced; first failure aborted the run	only daemon start failing yields 2 (test_daemon_lifecycle.py owns that surface as a regression, so the board loses nothing); every section runs and all failing ones are named
test_hook_augment.py / test_cli_non_ascii_arg.py: 300 chars of stdout on setup failure	full stdout and stderr

Verification

• Real Windows (UTM arm64 VM): win.sh guards — all guards GREEN, stability all 7 sections, guards rc=0.
• macOS (local iteration): guard GREEN in 1:35; isolation proof — a daemon started on the default rendezvous kept its pid (41915) across the whole guard, i.e. through three daemon stops and a kill -9 inside it.
• The failure formatting was exercised for real: the first local run refused every section (see below) and the new output named all seven with full text and the setup/red split.

Out of scope, noted

• test_daemon_lifecycle.py, test_non_ascii_path.py, test_ui_drive_listing.py still use the machine-global rendezvous — follow-up.
• POSIX only: a CBM_RUNTIME_DIR whose socket path exceeds sun_path (104 bytes on macOS) is refused at the ipc.c length check with no validation detail — the same opacity family as Claude.ai Desktop App still cannot start mcp #1582/CBM_CACHE_DIR ignored; daemon still requires /private/tmp/cbm-daemon-<uid> on macOS #1621. The guard keeps its POSIX namespace under /tmp for that reason.
• The fix(main): exit Windows stdio servers when the spawning client dies (#914) #1874 lifecycle signature itself (daemon accepts the connection, UI-config handshake unanswered) is a production-startup candidate this PR does not touch; this PR makes the next occurrence diagnosable instead of a cascade.