ci(render): make V9's first CI run green on both operating systems

The lavapipe job did the thing it was built to do on its first attempt.
It accepted a Cpu device at API 1.4, created a device and read pixels
back, captured a real frame, and exited 4 when a feature was forced
unsupported. Three other things were red, and none of them were the
Vulkan backend.

The shader-freshness step aborted for two separate Linux faults in the
compiler tool. Disposing the Silk.NET API container unloads the native
module, and dlclose-ing libshaderc_shared.so leaves glslang's
process-level teardown running against unmapped code. Bisected with a
four-mode probe on Ubuntu 24.04: GetApi, CompilerInitialize and
CompilerRelease each exit 0, and adding only the container Dispose turns
the exit into SIGSEGV. That is the 134 CI reported. shaderc's own handles
are still released; the container is not, because the module's lifetime
is the process's and the process is one statement from returning.
Separately, a portable dotnet build leaves the native under
runtimes/linux-x64/native/ and makes reaching it Silk.NET's probing
problem, which it solved on a local Ubuntu 24.04 and did not solve on the
runner. The script now publishes the tool for the host RID, so the native
sits beside the assembly where AppContext.BaseDirectory finds it, and
checks for it by name so a regression says which file is missing rather
than which names failed.

With both fixed, the question section 5.5.20 left open has an answer:
Linux shaderc and Windows shaderc agree byte-for-byte at the pinned Silk
2.23.0. Eighteen of eighteen .spv identical, manifest identical. The byte
comparison stays a byte comparison.

The Windows leg of portable-headless was running sudo apt-get. That step
is older than this campaign - it is red in the 2026-07-27 main run too -
and it was misplaced rather than mis-conditioned. Nothing in that job
opens a display or links GL, and the graphical jobs that do call xvfb-run
take it from the runner image, so the step is deleted rather than
guarded. Every remaining step in the two-operating-system matrix is pwsh;
every bash step now lives in an ubuntu-only job.

The last failure was ours in a quieter way. WaitForCharacterLogOff-
Confirmation expressed its deadline only as a CancellationTokenSource,
whose timeout is published from a thread-pool timer callback, so on a
saturated pool the token stays unsignalled past the deadline while the
loop keeps draining items that are already queued. That is the case the
method exists to bound. Reproduced by pinning the suite to two CPUs on
Linux, which failed 2 of 6 where four CPUs and sixteen were clean, and
where CI failed 3 of 3. The drain now reads the deadline off the
monotonic clock as well; the token still bounds the asynchronous wait.
Ten of ten clean under the same pin. The test is untouched. Filed as

Release build green. App tests 4,152 / 3 skipped against the same 4,152 /
3 measured at base 32f9bcfa. Core.Net 600 / 600.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -97,6 +97,50 @@ Copy this block when adding a new issue:
 
 ---
 
+## #254 — Logout confirmation wait overran its timeout on a starved thread pool
+
+**Status:** DONE — 2026-07-28; monotonic deadline added to the synchronous drain
+**Severity:** LOW (shutdown-path timing; no user-visible defect observed)
+**Filed:** 2026-07-28
+**Component:** net / session shutdown
+
+**Description:** `AcDream.Core.Net.Tests.WorldSessionShutdownTests.WaitForConfirmation_TimeoutWinsDuringContinuousUnrelatedDrain`
+failed on the `portable-headless (ubuntu-latest)` leg of the Headless
+portability workflow in **three CI runs out of three** (30259857711 on `main`,
+30386410215 and 30389334662 on the campaign branch), 599/600 each time, while
+the windows-latest leg never saw it. The assertion that fell was
+`Assert.True(processed < 100)`: the method drained all 100 queued items — about
+200 ms of work behind a 25 ms timeout — before noticing the deadline.
+
+**Root cause:** `WorldSession.WaitForCharacterLogOffConfirmation` expressed its
+deadline **only** as `CancellationTokenSource(TimeSpan)` and polled
+`IsCancellationRequested`. A CTS timeout is published from a thread-pool timer
+callback, so when the pool is saturated the token stays unsignalled well past
+the deadline while the drain loop keeps consuming already-queued items — exactly
+the case the method exists to bound. This is a real (if small) product defect,
+not a test artifact: on a loaded machine the client's logout wait could overrun
+its own timeout by the length of whatever is already sitting in the inbound
+queue.
+
+**Evidence:** not reproducible on Windows (5/5 suite runs clean) nor on native
+Linux with 16 cores (8/8 clean). Reproduced by pinning the suite to two CPUs on
+Ubuntu 24.04 — `taskset -c 0,1` — which failed 2 runs out of 6; the same pin at
+four CPUs was clean 6/6. GitHub-hosted `ubuntu-latest` is 4-core and slower than
+the local pin, which is why CI saw it every time.
+
+**Fix:** the drain loop now also compares `Stopwatch.GetElapsedTime` against the
+requested timeout, so the deadline is read off the monotonic clock rather than
+only off a thread-pool callback. The CTS is kept — it still bounds the
+asynchronous `WaitToReadAsync`. A negative timeout keeps its framework meaning
+of "infinite". Ten of ten suite runs clean under the same two-CPU pin
+afterwards. **The test was not modified.**
+
+**Files:** `src/AcDream.Core.Net/WorldSession.cs` (the internal generic
+`WaitForCharacterLogOffConfirmation`), asserted by
+`tests/AcDream.Core.Net.Tests/WorldSessionShutdownTests.cs:203`.
+
+---
+
 ## #253 — Attribute/skill icons: not centered in their cells, and fully opaque
 
 **Status:** OPEN

docs/plans/2026-07-27-vulkan-campaign.md

@@ -3257,6 +3257,68 @@ should name its measurement vehicle, because the obvious candidate is the wrong
 one and cost this slice an hour to establish; and the founding numbers should be
 labelled with their scene, because Caul and Aerlinthe differ by more than the
 entire GL-versus-Vulkan CPU gap.
+#### 5.5.22 V9's first CI runs: the answer on determinism, and three failures
+
+The `linux-vulkan` job did what it was built to do on its first attempt. Steps
+(a), (b) and (c) all passed on lavapipe: the gate accepted a `Cpu` device at API
+1.4, the active probe created the device and read pixels back, the captured PNG
+was a real frame, and the forced-unsupported run exited 4 with a report naming
+the feature. **The first CI job in the project's history that renders a frame
+rendered one.**
+
+Step (d) aborted, and two failures elsewhere came with it.
+
+**The determinism verdict: byte-identical, yes.** §5.5.20 left one thing
+asserted-but-unobserved — whether Linux shaderc and Windows shaderc agree
+byte-for-byte at the same pinned Silk.NET 2.23.0. **They do.** Measured directly
+rather than inferred: the same GLSL sources compiled on Ubuntu 24.04 through the
+package's `linux-x64` native produce **18/18 `.spv` byte-identical** to the
+committed Windows-produced artifacts, and a parsed-JSON manifest compare is
+clean. So the byte comparison in step (d) is the right instrument and needs no
+softening — neither pinning a single compiler build nor falling back to a
+structural `spirv-dis` compare. The pinned NuGet native is already the pin.
+
+**Why (d) aborted anyway: two Linux faults in the tool, not in the shaders.**
+
+1. **`Shaderc.Dispose()` kills the process on Linux.** Disposing the Silk.NET API
+   container unloads the native module, and `dlclose`-ing `libshaderc_shared.so`
+   leaves glslang's process-level teardown to run against unmapped code. Bisected
+   with a four-mode probe on Ubuntu 24.04: `GetApi`, `CompilerInitialize` and
+   `CompilerRelease` each exit 0, and adding **only** the container `Dispose`
+   turns the exit into SIGSEGV. That is what CI reported as exit 134. shaderc's
+   own handles are still released; the container is not, because the module's
+   lifetime is the process's and the process is one statement from returning.
+
+2. **A portable `dotnet build` does not reliably put the native where it can be
+   found.** It leaves `libshaderc_shared.so` under `runtimes/linux-x64/native/`
+   and makes reaching it the job of Silk.NET's probing chain, which resolved it
+   on a local Ubuntu 24.04 and did **not** on the ubuntu-24.04 runner —
+   `Could not load from any of the possible library names!` at `GetApi`. The
+   script now **publishes** the tool for the host RID, which flattens the native
+   beside the assembly where `AppContext.BaseDirectory`, the first candidate
+   Silk.NET tries, always finds it, and then checks the file is there by name so
+   a future regression says which file is missing instead of which names failed.
+
+**The two failures outside the Vulkan job.**
+
+3. **The `portable-headless` matrix ran `sudo apt-get` on windows-latest** and
+   exited 127. Pre-existing since L1 (`11501d52`) rather than introduced here —
+   the same step is red in the `main` run of 2026-07-27 — and it was misplaced
+   rather than mis-conditioned: that job builds the presentation-free closure and
+   the Headless CLI, nothing in it opens a display or links GL, and the graphical
+   jobs that *do* call `xvfb-run` take it from the runner image. Deleted.
+
+4. **`WaitForConfirmation_TimeoutWinsDuringContinuousUnrelatedDrain` failed on
+   the ubuntu leg**, 3 CI runs out of 3, while passing on Windows. Not a flake
+   and not the campaign's: `CancellationTokenSource(TimeSpan)` publishes its
+   cancellation from a thread-pool timer callback, so on a saturated pool the
+   token stays unsignalled past the deadline while the drain loop keeps
+   consuming already-queued items — the precise case the method exists to bound.
+   Reproduced by pinning the suite to two CPUs on Linux (2 failures in 6; clean
+   at four and at sixteen, and clean on Windows). Fixed at the cause by reading
+   the deadline off the monotonic clock in the synchronous drain as well as off
+   the token, which still bounds the asynchronous wait. Ten of ten clean under
+   the same two-CPU pin afterwards. The test was not touched.
 
 ### 5.4 The null-target `BeginPass` divergence (V4c) — ✅ DISCHARGED at V6k