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

spikes/README.md

@@ -87,12 +87,16 @@ 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** (`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.
+**Answered on 2.9.4: it cannot.** The constructor is lazy and always succeeds — judging by it is
+what made the first reading of this probe wrong. `Start()` is where the service is consulted, and
+a second `Start()` on a running name fails with `ERROR_ALREADY_EXISTS` (0x800700B7). Note it is
+*not* `WSLC_E_SESSION_RESERVED`, which exists in `wslc.idl` but evidently means something
+narrower — don't key on it.
+
+So the probe judges on `Start()`. If a future version lets the second `Start()` through, it 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.
 
 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