test(app): put every strict-zero site on the probe (#250)

The first commit converted the four members the issue named and left the other
sites alone, reasoning that none had been observed failing. A 20-run
complete-solution baseline disproved that within minutes:

  run  2  LiveEntityRuntimeTests.AnimationView_HotSpatialTraversal…
  run 14  StaticRenderProjectionJournalTests.ActiveAnimatedSynchronization…
  run 18  StaticRenderProjectionJournalTests.ActiveAnimatedSynchronization…
  run 19  CurrentRenderSceneOracleTests.SurfaceOverrideFingerprint…

Both new names are the same shape as the four — one warm call, then a
thousand-iteration loop inside the measured window — and neither had been
recorded anywhere. "Not observed failing" only ever meant "not yet observed",
and leaving known-shape sites in place would have guaranteed the acceptance gate
failed. Run 19 is the sharper lesson: the issue named
`SurfaceOverrideFingerprint_DictionaryHotPathAllocatesNothing`, and the first
commit converted a *different* test in that same file, so the actually-named
member was still on the old shape. Matching by file was not matching by test.

Every strict-zero site in the assembly is now on the probe — ten tests. Two came
out stricter rather than merely steadier:

`StaticRenderProjectionJournalTests` was measuring a synchronise whose journal
does **not** coalesce. Repeating it grew the journal by 1,000 entries per call —
192,000 by the end of a probe run — so the steady state the test claimed to
measure did not exist and the single-call window had been hiding it. Its step is
now the whole frame cycle, synchronise *and* drain, which puts `DrainTo` inside
the measured window for the first time and asserts the journal ends empty.

`RetailInboundEventDispatcherTests` asserted a hard-coded 1,001 callbacks. It
now counts its own dispatches and pins the callback count against that, so the
assertion still proves the fast path ran the callback every time without being
coupled to a loop bound that no longer exists.

Left alone deliberately: the four sites asserting a tolerance rather than zero —
`CellViewDedupTests` and `PortalProjectionTests`. Their ceilings already absorb
this noise and none has flaked; changing a bound in either direction is a
separate decision from fixing a measurement. Worth noting that
`PortalProjectionTests`' ceiling exists explicitly to tolerate "a
tiered-JIT/ArrayPool bookkeeping transition ... to the first measured batch",
which is exactly what the probe removes, so it could probably be tightened to
zero now — recorded in the issue rather than done here.

Solution build 0 warnings / 0 errors; App suite 3,941 passed / 3 skipped.

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

docs/ISSUES.md

@@ -750,17 +750,39 @@ cost reads as zero; a cost every tenth call is caught; and the stated limit —
 the batch must cover the period — is pinned rather than left as prose. Without
 those, a later edit could quietly make the whole family unfailable.
 
-**Not yet done:** twelve further `GetAllocatedBytesForCurrentThread` sites in
-`AcDream.App.Tests` still use the hand-rolled shape (`CellViewDedupTests`,
-`EquippedChildProjectionWithdrawalTests`, `PortalProjectionTests`,
-`RenderFrameRouteOwnerSelectorTests`, `StaticRenderProjectionJournalTests`,
-`PackedProjectionClassificationCacheTests`,
+**The family was larger than four.** The first attempt converted only the four
+members the issue named and left the rest, on the grounds that none had been
+observed failing. A 20-run complete-solution baseline immediately disproved
+that: `LiveEntityRuntimeTests.AnimationView_HotSpatialTraversalDoesNot`
+`AllocateAfterWarmup` failed in run 2 and
+`StaticRenderProjectionJournalTests.ActiveAnimatedSynchronization_Reuses`
+`RetainedJournalStorage` in runs 14 and 18 — both the same shape, neither
+previously recorded. "Not observed failing" only ever meant "not yet observed".
+
+So **every strict-zero site in the assembly is now on the probe** — ten tests:
+the four named members plus `LiveEntityRuntimeTests`,
+`StaticRenderProjectionJournalTests`, `RenderFrameRouteOwnerSelectorTests`,
 `GpuWorldStateRenderTraversalTests`, `UiTextLayoutCacheTests`,
-`LiveEntityRuntimeTests`, `RetailInboundEventDispatcherTests`, and a second
-site in `CurrentRenderSceneOracleTests`). None has been observed failing.
-Each needs its own repeatability analysis — several mutate state or consume
-monotonic sequences — so they were left alone rather than converted blind.
-Adopt the probe when one is next touched, or immediately if it flakes.
+`RetailInboundEventDispatcherTests`, `PackedProjectionClassificationCacheTests`
+and `EquippedChildProjectionWithdrawalTests`.
+
+Two of those got stricter rather than merely steadier.
+`StaticRenderProjectionJournalTests` turned out to be measuring a synchronise
+whose journal **does not coalesce** — repeating it grew the journal by 1,000
+entries per call, so the steady state it claimed to test did not exist. Its step
+is now the whole frame cycle, synchronise *and* drain, which puts `DrainTo`
+inside the measured window for the first time.
+`RetailInboundEventDispatcherTests` now counts its own dispatches and pins the
+callback count against them, where before it asserted a hard-coded 1,001.
+
+**Deliberately not converted:** the four sites that assert a *tolerance* rather
+than zero — `CellViewDedupTests` (two, `<= 256`) and `PortalProjectionTests`
+(two, `<= 1_024` and `<= 4_096`). Their ceilings already absorb the noise this
+issue is about, none has been observed failing, and touching their bounds in
+either direction is a separate decision. `PortalProjectionTests` is worth
+revisiting: its ceiling exists explicitly to tolerate "a tiered-JIT/ArrayPool
+bookkeeping transition ... to the first measured batch", which is precisely what
+the probe removes, so it could likely be tightened to zero on the probe now.
 
 ---