merge(net): the wire-stack audit, and one reconciled #255

Brings `github/overnight/wire-audit` (`41f74fcd`) forward onto the V11 tree.
Like the enum branch it was cut at `b70b9832`, and like the enum branch its
subject is disjoint from the deletion: the audit lives in `AcDream.Core.Net`
and its tests, V11 emptied `AcDream.App`. One conflict, in `docs/ISSUES.md`,
resolved below.

What it carries: three real parser fixes — ranged speech was carrying a range
float the parser ate, a chat type that is never sent was silently dropping every
transient string on it, and `xpSpent` is a dword on the wire where we were
writing eight bytes. Plus the transport flag word pinned against ACE across all
twenty-three bits, golden fixtures generated from ACE's own writer instead of
hand-typed hex, and the audit document covering all three hundred forty-nine
opcodes.

**The conflict, and how it was resolved.** Both this branch and V11's closeout
reopened #255 — the RetailDatLoader concurrency tests that measure the thread
pool rather than the loader — on the same day, from different trees, without
knowing about each other. Neither reopening is a duplicate of the other: the
V11 gate saw 2 failures in 5 complete-solution Release runs on the
post-deletion tree, the audit session saw 2 in 4 on the pre-deletion tree, and
both saw 124/124 in isolation every time. They independently reached the same
conclusion, that `TaskCreationOptions.LongRunning` is a hint rather than a
guarantee, and independently proposed the same fix, a rendezvous inside the read
stub.

So the two notes are merged into one issue with both evidence sets kept as
labelled subsections rather than one overwriting the other. Four failures across
nine runs on two trees is a materially stronger case than either half, and the
agreement between two blind observations is the part worth preserving. No
assertion was weakened and no retry was added; the fix itself remains open.

Verified on the merge result: Release build 0 errors, and
`AcDream.Core.Net.Tests` at 659 passed / 0 skipped, up exactly the 59 the branch
claimed.

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

docs/ISSUES.md

@@ -190,7 +190,10 @@ tree is recoverable from git history at `844cf092^`.
 
 ## #255 — Two RetailDatLoader concurrency tests measured the thread pool, not the loader
 
-**Status:** REOPENED 2026-07-29 — the `LongRunning` fix is a hint, not a guarantee
+**Status:** REOPENED 2026-07-29 — the `LongRunning` fix is a hint, not a
+guarantee; `AnimationCache_Coalesces…` still fails under full-suite load on
+Windows. Reopened independently by two sessions on the same day; both evidence
+sets are kept at the end of this issue.
 **Severity:** LOW (test infrastructure only; no production defect)
 **Filed:** 2026-07-28
 **Component:** tests / xUnit parallelism, content loaders
@@ -225,7 +228,14 @@ afterwards.
 
 **Files:** `tests/AcDream.Content.Tests/Vfx/RetailDatLoaderTests.cs`.
 
-### Reopened 2026-07-29 by the V11 gate
+### Reopened 2026-07-29 — two independent sessions, one diagnosis
+
+Two overnight sessions hit this on the same day, on different trees, and reached
+the same conclusion without knowing about each other. Both evidence sets are
+recorded below because they probe different pressure regimes and agree, which is
+what makes the diagnosis solid rather than anecdotal.
+
+#### Evidence set A — the V11 gate (post-deletion tree)
 
 `AnimationCache_CoalescesSameDidAndAllowsUnrelatedReadsInParallel` failed again
 on Windows, at `RetailDatLoaderTests.cs:311` (`Assert.True(portal.MaxConcurrentReads >= 2)`),
@@ -251,6 +261,34 @@ coalescing, which is what it is for, and makes it independent of how many
 threads the host happens to offer. **Do not weaken the assertion or add a
 retry** — the assertion is correct; the harness around it is what is wrong.
 
+#### Evidence set B — the wire-stack audit session (pre-deletion tree)
+
+Observed independently on `b70b9832`, a tree that already contains the
+`LongRunning` fix (`c7861020`) in its base lineage: **2 failures in 4 full-suite
+runs**, with the project passing **124/124 every time it is run alone**. Both
+failures were `--no-build` runs, which start the projects faster and so apply
+more parallel pressure — consistent with the original diagnosis rather than a
+new cause.
+
+`PhysicsScriptLoader_AllowsConcurrentFirstReads` was not observed failing in
+that session, but it shares the helper and should be treated as the same risk.
+
+That session changed nothing under `AcDream.Content`; its diff was confined to
+`src/AcDream.Core.Net`, that project's tests, and `docs/`. So neither reopening
+is explained by the tree it was observed on — set A's V11 diff touches
+`AcDream.Content` only in pixel-format enum documentation, and set B's touches
+it not at all.
+
+#### What the two sets agree on
+
+Four full-suite failures across nine runs on two different trees, against
+124/124 in isolation every time. The fix direction is the same from both
+sides: synchronise the two callbacks against **each other** — a `Barrier` or
+two-party `SemaphoreSlim` rendezvous *inside* the read stub — so neither read
+can complete until both have entered. Then `MaxConcurrentReads == 2` is a
+property of the loader rather than of the scheduler, and the test cannot flake
+no matter how loaded the box is.
+
 ---
 
 ## #254 — Logout confirmation wait overran its timeout on a starved thread pool