Merge nucleic/olive-jade-civet-rznt into dev

spikes/README.md

@@ -33,7 +33,8 @@ Two facts it discovered that anything referencing this package needs:
 cd windows/spikes/WslcApiDump
 dotnet run                      # dump the API + check every facade assumption
 dotnet run -- --probe           # + GetMissingComponents / GetVersion
-dotnet run -- --session         # + create a session, then a SECOND one with the same name
+dotnet run -- --session         # + create a session, a SECOND with the same name, identity-test, tear down
+dotnet run -- --session --keep  # …and leave the sessions running afterwards
 dotnet run -- --all-types       # include the ABI/marshalling plumbing in the dump
 ```
 
@@ -86,17 +87,23 @@ name**. That second construction is the whole point, and it is the last open que
 on: the compat SDK exposes a `Session` *constructor* and no attach, so does constructing over an
 existing name re-adopt it, or refuse?
 
-- **Refused** (expect `WSLC_E_SESSION_RESERVED`, `0x80040607`) — D13's premise is confirmed on
-  hardware rather than inferred from an IDL, and session reattach genuinely requires
-  `IWSLCSessionManager::OpenSessionByName` on the internal interface.
-- **Constructed** — the compat surface may re-adopt by name, and the session half of §2.3 reattach
-  may not need the internal interface at all. Check `wslc container ps` for the first session's
-  containers before believing it.
+- **Refused** (`WSLC_E_SESSION_RESERVED`, `0x80040607`) — D13's premise is confirmed, and session
+  reattach genuinely requires `IWSLCSessionManager::OpenSessionByName` on the internal interface.
+- **Constructed** — which is what 2.9.4 actually does. That alone proves nothing (construction may
+  be lazy), so the probe then runs an **identity test**: terminate the FIRST session and read from
+  the SECOND. A read that worked before and fails after is one underlying session answering both
+  handles; a read that keeps working means two independent VMs were running.
 
-It leaves the session running on purpose, because that is the other half of the same question:
-broker supervision assumes wslc state is **service-backed**, so a crashed `nucleic-brokerd` can
-re-adopt rather than orphaning containers. If `wslc session ls` still shows `nucleic-spike` after
-this process exits, that holds. Tear it down with `wslc` when you're done.
+The identity test deliberately uses only the compat SDK. The obvious check would be
+`wslc session ls` — but **`wslc.exe` is not on PATH by default**, so a spike that depends on it
+answers nothing on a stock machine. (It ships beside `wsl.exe`; try
+`C:\Program Files\WSL\wslc.exe`. That it isn't on PATH is one more small argument for D13's
+no-CLI stance.)
+
+Sessions are **torn down at the end** by default — an earlier version left a WSL VM running and
+told you to clean it up with a command that doesn't exist. Pass `--keep` to leave them, which is
+how you check the other half of the §2.3 question: whether session state outlives the process that
+created it. With `--keep`, `wsl --shutdown` clears everything.
 
 The gateway address is *not* what this probe is for any more — §13.1 established that no API
 surfaces one, and D13 moves the control plane to hvsocket via `IWSLCVirtualMachine::GetId`.