fix(physics): close the AP-156 fix review — real containment oracle, type-level invariant, AP-158

Both review lenses PASSED; this is the cleanup, not a rescue. Evidence:
docs/research/2026-08-06-ap156-review-closure.md (the review itself is
committed alongside it as the received artifact).

R1 — the load-bearing containment test could not fail. Its truth and flood
values were two hand-copies of the same expression over the same part set,
so the shortfall was algebraically identically zero for any DAT input. The
oracle is now PHYSICS-POLYGON VERTICES — a different DAT field from the
bounding sphere the builder emits, so the two sides can genuinely disagree.
Sabotage-verified three ways after full cleans: dropping the bounds centre
in production reddens it (428 Setups, worst 35.869 m on 0x0200129A, matching
an independent out-of-repo sweep exactly); dropping only the scale on the
centre reddens it (326); and corrupting the TEST's own bounds oracle reddens
it (467) where under the shipped oracle that same corruption was invisible
by algebra. Renamed accordingly. A6's stale "cap control" comment corrected:
that loop is the test's own uncapped re-implementation and cannot observe a
cap regression — the cap is covered in Core.

R2 — the population was understated. 172 is AP-152's DISPATCH population;
AP-156's is 530 BSP-bearing Setups, of which 525 have a flood sphere move
and 428 fail vertex containment before the fix (412 at a 1 cm tolerance —
the review's figure; the gap is 16 Setups between 1.4 mm and 10 mm, real
geometry). 0 fail after, at any tolerance down to zero. Corrected in the
AP-156 row, the section-3 header, the C5c handoff and two test docstrings.
Dated review artifacts are left as written — "170 of 172" was correct for
what they measured, and rewriting evidence to match a later measurement
loses provenance.

A1 — BoundsCenter = default reopened at the type what the commit closed at
the seam. Dropping the default alone would NOT have closed the review's own
scenario (a copied Cylinder call site would write Vector3.Zero explicitly
and stay green), so ShadowShape's constructor is now private and BSP shapes
are built only through ShadowShape.Bsp(..., FlatCollisionSphere localBounds),
which takes radius and centre as ONE value and scales them together. There
is no expression a caller can write that carries one and drops the other.
22 construction sites converted; the same sabotage now reddens 5 Core tests
where the review's sabotage A reached 4, because both BSP producers share
one scaling path.

A2 — #333 is real and bigger than filed, and its retail question is
answered. I disassembled CObjCell::find_obj_collisions @0x0052b750 from the
PDB-paired binary myself (check_exe_pdb.py MATCH) rather than inheriting the
claim: its only early-out is sphere_path.insert_type == INITIAL_PLACEMENT_
INSERT, then it calls FindObjCollisions on every unparented non-self shadow
object UNCONDITIONALLY. Retail has NO distance pre-filter, so acdream's
"+ movement + 2f" reach filter is an invention with no register row — filed
as AP-158, carrying the disassembly, the F_EPSILON = 0.0002 m contrast, and
the measured blast radius (118 of 477 unique installed physics-BSP GfxObjs
exceed its ~2.5 m budget, 46 exceed 5 m). Active AP rows 109 -> 110.

Recorded prominently in three places a reader will hit: TALL PROPS MAY SHOW
NO VISIBLE CHANGE UNTIL #333 LANDS, and a null result at the connected gate
is EXPECTED, not evidence against AP-156.

LOW items. R3: the comment claiming the cited evidence justified the whole
cap line is corrected, but int.MaxValue on the sorting-sphere branch stays —
capping at 1 would take Spheres[0], and retail's one sphere is
CSetup::sorting_sphere, a different DAT field; capping keeps the wrong field
AND flips the substitution under-inclusive (#98/#168 direction). AP-157
already owns it. R4: acdream scales the flood sphere where retail's
find_transit_cells never reads gfxobj_scale — added as a second residual on
AP-156. R5: retail's slack constant carried into AP-158 and #333. A3: the
per-call delegate allocation is back to a cached field, still derived from
the single bounds resolver. A5: noted; b52967de's message cannot be amended.

Gates: all 44 bin/obj deleted before every verdict-deciding build, each test
run gated on a verified "Build succeeded" in the same invocation. Release
build 0 errors / 21 pre-existing warnings. Complete suite 11,208 passed /
4 skipped / 0 failed — reconciles exactly with the e2b2d04c baseline; one
test renamed, none added, removed or skipped. Nothing conflated with the
known load-sensitive flakes #302 / #308 / #321.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/AcDream.Core/Physics/ShadowObjectRegistry.cs

@@ -663,14 +663,28 @@ public sealed class ShadowObjectRegistry
 
         // The 10-sphere clamp belongs to the CYLSPHERE branch alone.
         // CObjCell::find_cell_list @0x0052b9f0 clamps the cylsphere count at
-        // 0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa. The BSP branch —
-        // find_bbox_cell_list @0x00510fc0 -> CPartArray::calc_cross_cells_static
-        // @0x00518160 -> CEnvCell::find_transit_cells @0x0052cae0 — walks EVERY
-        // part with no cap, and the sorting-sphere overload @0x0052b990 takes a
-        // single sphere. Applying the clamp to the BSP branch dropped parts
-        // 11..N out of the flood entirely: 7 installed Setups carry more than
-        // 10 physics-BSP parts (max 49, Setup 0x02001A91), and landblock-baked
-        // part arrays — stair runs, fences, rock clusters — routinely do.
+        // 0x0052ba21 cmp eax,0xa / 0x0052ba28 mov ebp,0xa, and that clamp is a
+        // fixed static-buffer capacity (the destination array at
+        // 0x844838..0x8448d8 is exactly ten 16-byte entries), not a policy.
+        //
+        // BSP branch: NO CAP, and this is a retail port. find_bbox_cell_list
+        // @0x00510fc0 -> CPartArray::calc_cross_cells_static @0x00518160 ->
+        // CEnvCell::find_transit_cells @0x0052cae0 walks every part, bounded
+        // only by num_parts. Clamping it dropped parts 11..N out of the flood
+        // entirely: 7 installed Setups carry more than 10 physics-BSP parts
+        // (max 49, Setup 0x02001A91), and landblock-baked part arrays — stair
+        // runs, fences, rock clusters — routinely do.
+        //
+        // only == null (the sorting-sphere branch): int.MaxValue is NOT a
+        // retail port and the addresses above do not justify it. Retail's
+        // overload @0x0052b990 pushes a literal 1 (0x0052b9d6 push 1) and
+        // floods from ONE authored CSetup::sorting_sphere. acdream floods from
+        // every Sphere shape instead — a different DAT field with a different
+        // cardinality, which is AP-157, filed and open. Capping at 1 HERE would
+        // not move toward retail: it would take Spheres[0], which is not the
+        // sorting sphere. int.MaxValue keeps the substitution in its safe
+        // (over-inclusive) direction until AP-157 ports the real field. Inert
+        // over installed data — max 5 Spheres on any Setup (0x020016F7).
         int cap = only == ShadowCollisionType.Cylinder ? RetailSphereCap : int.MaxValue;
 
         foreach (var s in shapes)