test(content): give the loader concurrency tests real concurrency

Fixing the two failures that were stopping portable-headless earlier let
the job reach AcDream.Content.Tests for the first time on either
operating system - the test loop exits on the first failing project, so
the windows leg had never got past the apt step and the ubuntu leg had
never got past Core.Net. Two RetailDatLoaderTests cases were waiting
there, and they failed on both.

Both assert on RawDatabase.MaxConcurrentReads after issuing two Task.Run
reads that each block 40 ms in Thread.Sleep. A pair of pool work items is
not a guarantee of two workers in flight: on a low-core or saturated pool
the second queues behind the first, the reads run back to back,
MaxConcurrentReads stays 1, and the assertion fails for a reason that has
nothing to do with the loader. Pinning the suite to two CPUs on Ubuntu
reproduces it 5 times in 6; Windows is clean 6 of 6 at sixteen cores,
which is why nobody had seen it.

The pairs now start with TaskCreationOptions.LongRunning on the default
scheduler, which asks for a thread each. No assertion is changed - they
still fail if the loader serialises. The two coalescing cases moved onto
the same helper on purpose: two callers genuinely in flight is the
situation coalescing exists for, and a sequential pair was only ever
exercising a cache hit. Ten of ten clean under the same pin.

Release build green. App tests 4,152 / 3 skipped. Content 124 / 124.
Filed as #255.

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

docs/ISSUES.md

@@ -97,6 +97,45 @@ Copy this block when adding a new issue:
 
 ---
 
+## #255 — Two RetailDatLoader concurrency tests measured the thread pool, not the loader
+
+**Status:** DONE — 2026-07-28; the pair now runs on dedicated threads
+**Severity:** LOW (test infrastructure only; no production defect)
+**Filed:** 2026-07-28
+**Component:** tests / xUnit parallelism, content loaders
+
+**Description:** `AcDream.Content.Tests.Vfx.RetailDatLoaderTests.AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel`
+and `.PhysicsScriptLoader_AllowsConcurrentFirstReads` failed on **both** legs of
+`portable-headless` in run 30392764012. They were previously invisible: the
+ubuntu leg died in Core.Net (#254) before reaching `AcDream.Content.Tests`, and
+the windows leg died at an even earlier step (the misplaced `sudo apt-get`), and
+the workflow's test loop exits on the first failing project.
+
+**Root cause:** both assert on `RawDatabase.MaxConcurrentReads` after issuing two
+`Task.Run` reads, each of which blocks 40 ms in `Thread.Sleep`. A pair of pool
+work items does not guarantee two workers are ever in flight: on a low-core or
+saturated pool the second queues behind the first, the two reads run back to
+back, `MaxConcurrentReads` stays 1, and the assertion fails for a reason that has
+nothing to do with the loader. Same family as #252 and #254 — a test asserting a
+real-time/parallel property under an unbounded-parallelism test host.
+
+**Evidence:** clean on Windows locally (6/6 full-suite runs, 124/124 each).
+Reproduced by pinning the suite to two CPUs on Ubuntu 24.04 (`taskset -c 0,1`):
+**5 failures in 6 runs**, the same two tests every time.
+
+**Fix:** a private `InParallel` helper starts both callbacks with
+`TaskCreationOptions.LongRunning` on `TaskScheduler.Default`, which asks for a
+thread each, so the concurrency the assertions measure is actually offered. **No
+assertion changed** — they still fail if the loader serialises. The two
+coalescing tests were moved onto the same helper deliberately: two callers
+genuinely in flight is the situation coalescing exists for, where a sequential
+pair only ever exercised a cache hit. 10/10 clean under the same two-CPU pin
+afterwards.
+
+**Files:** `tests/AcDream.Content.Tests/Vfx/RetailDatLoaderTests.cs`.
+
+---
+
 ## #254 — Logout confirmation wait overran its timeout on a starved thread pool
 
 **Status:** DONE — 2026-07-28; monotonic deadline added to the synchronous drain