docs(worker): reviewer follow-up comments and tests from the remediation reviews

The worker-side half of the review tail. Tests and comments only — nothing here
changes worker behavior, and none of it compiles on the macOS tree (net48/x86),
so it was reviewed line by line against the already-windev-validated files.

- MxAccessHandleRegistryTests gains the multi-candidate case behind
  MxAccessSession.TryGetCachedReadFor's fall-through: one tag under two item
  handles, the lower registered-but-unadvised and the higher advised. Asserted
  at the registry rather than the session because the session's read path needs
  a live MXAccess COM instance; what the registry owes the scan is the stable
  ascending candidate order and a per-item-handle (not per-tag) advice index,
  and both are pinned here along with the fall-through contract in prose.
- A single adversarial lifecycle test — register, advise, re-register the same
  item handle under a new tag, unadvise, unregister the server — asserting every
  index agrees after each step. The individual transitions were already covered;
  what was not was that they compose, and a stale entry in any one index
  resurrects a handle MXAccess has already retired.
- StaWaitHelperTests.WaitForSignalOrMessages_PreSignalledHandle_ReturnsImmediately
  drains pending messages first, like the other two wait tests. Without it a
  stale message can end the wait instead of the handle, failing the
  signal-consumed post-condition for an unrelated reason.
- GatewayTesting.md records the two findings from the Task 24 windev gate:
  SecretsStorePathGuardTests.CreateBuilder_AcceptsSecretsStoreOutsideContentRoot_AndCreatesIt
  fails deterministically on Windows on main too (SQLite pooling holds secrets.db
  open across the cleanup's recursive delete; pre-existing, tracked separately),
  and the StaWaitHelper timing tests' flake signature on a loaded box is a
  message wake — the helper working as designed — not a broken wait.

docs/GatewayTesting.md

@@ -554,6 +554,23 @@ windev has 36 logical CPUs and `xunit.runner.json` sets `maxParallelThreads: -1`
 suite runs far wider there than on the macOS dev box — that width is what turns these
 real-clock deadlines into failures.
 
+### Two more findings from the 2026-08-15 windev gate
+
+- `SecretsStorePathGuardTests.CreateBuilder_AcceptsSecretsStoreOutsideContentRoot_AndCreatesIt`
+  fails **deterministically on Windows, on `main` as well as on any branch**, so it is not a
+  signal about the change under test. Creating the builder opens `secrets.db`, and
+  `Microsoft.Data.Sqlite`'s connection pool keeps the file handle alive past the test body,
+  so the recursive directory delete in the cleanup hits a still-open file — a sharing
+  violation Windows enforces and Unix does not. Pre-existing and tracked separately; do not
+  chase it as a regression. Subtract it from the expected pass count on Windows.
+- The `StaWaitHelper` timing tests (`WaitForSignalOrMessages_*`) flake on a loaded box with a
+  signature that reads like a broken wait but is not: the helper wakes on *input being
+  present*, so a message posted to the test thread ends the wait early. That is the helper
+  doing exactly what the STA pump needs. The tests drain the queue with
+  `PumpPendingMessages()` first for that reason; a failure here means the box was busy enough
+  to queue a message mid-test, not that the wait stopped honouring its handle or its timeout.
+  Re-run the class on its own before treating it as real, per the load caveat above.
+
 ### The full-suite testhost hang was a zero-buffer named pipe (fixed)
 
 For months a full-suite run on windev reported `855 passed, 0 failed` and then never