fix(physics): port retail's find_bbox_cell_list outdoor extent walk (#334)

acdream had never implemented retail's SECOND cell-membership algorithm.
CPhysicsObj::calc_cross_cells @0x00515230 tests HAS_PHYSICS_BSP_PS at
0x00515285 and jumps (0x0051528f jne 0x515305) to find_bbox_cell_list
@0x00510fc0 for a BSP-bearing object; everything below that jump is the
OTHER algorithm, CObjCell::find_cell_list, and that is all we had. Every
object, BSP-bearing or not, was routed through it.

That path's outdoor expansion is a HARD CAP of one cell in each direction.
CellTransit.AddAllOutsideCells computes minRad = radius, maxRad = 24 - radius
and adds at most the eight neighbours of the sphere's own cell, so for any
radius >= 12 m both boundary tests are unconditionally true and the result is
exactly 3x3. Widening the radius or adding a second sphere is mechanically
incapable of adding a tenth cell. The user's live probe measured the
consequence directly: standing inside a Neftet formation, inCell=2 exempt=2
reached=0 -- the geometry was not a candidate at all.

The port. AddAllOutsideCellsFromParts is CLandCell::add_all_outside_cells
@0x00533360 plus add_cell_block @0x005331d0: base landcell from the FIRST
part's own adjust_to_outside, baseX/baseY within-block, each part's authored
CGfxObj::gfx_bound_box re-fit through all eight corners
(BBox::LocalToGlobal @0x005b2120), floor(v / square_length) where
square_length = 0x7c920c = 24.0f, four accumulators seeded to zero, ONE
rectangle unioned across all parts, FILLED, in GLOBAL lcoords so it crosses
landblocks freely, clamped only to [0, 0x7f8).
BuildShadowCellSetFromParts is find_bbox_cell_list's worklist.
RegisterMultiPart dispatches on the same flag retail does, and
BuildFloodSpheres' BSP arm is deleted rather than left unreachable.

Disassembled from the PDB-paired 2013-09-06 binary, not read from Binary
Ninja: BN mis-renders four separate constructs inside add_all_outside_cells
alone -- a dropped `and eax,0xffff` on baseX, a neg/sbb/and select shown as
identically zero, a wrong get_landcell argument, and both x87 flag tests as
`unimplemented {test ah}`.

ShadowPartGeometry pairs the BSP root sphere with the authored box so no
resolver can answer one and leave the other call site to synthesize a
substitute -- the AP-156 invariant applied a second time, since that split is
what produced AP-156 and then this. The box comes from
FlatGfxObjVisualBounds, already computed by exactly CGfxObj::init_end's
algorithm and already in the prepared package: no bake change, no DAT re-read.

Cost, measured over the installed DATs before any code was written: 1,258
physics-BSP GfxObjs, cells/object p50 4, p90 4, p99 12, max 49. The port is
CHEAPER than the old 3x3 = 9 for 98.97% of them. Row totals (shapes x cells)
over all 1,031 landblocks with BSP owners fall 97,173 -> 15,607 (0.161x);
dense Arwic 0xC6A9 falls 342 -> 43. One landblock more than doubles.

Precondition confirmed before pinning any expected cell set: 0x010046D8's box
is 96 m x 96 m about cell (2,2) = 0x87640013, which independently corroborates
the 3x3-centred-there diagnosis, and its rectangle does contain 0x87640011 and
0x87640019 -- the two cells the probe measured empty.

Register: AP-156's outdoor half CLOSED and its risk column CORRECTED (it read
"extra broadphase candidates, never a missed one", which generalised the indoor
direction to the whole row and is why #334 sat inside it unnoticed). AP-159 +
issue #335 file the unported indoor arm; AD-49 records the seed-time rectangle.
Issue #336 files a fourth load-sensitive test flake seen once during the gate.

Ten tests, every one sabotage-verified in both directions across eight
mutations (dispatch, 8-corner refit, floor-vs-truncation, union-vs-per-part,
map clamp, adjust guard, landblock clamp, box-path-for-everything). The
strongest is an installed-DAT replay of the user's own probe evidence.
Suite 11,208 -> 11,218 passed / 4 skipped / 0 failed; the +10 is exactly the
new tests.

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

src/AcDream.App/Physics/LiveEntityCollisionBuilder.cs

@@ -47,7 +47,7 @@ internal sealed record LiveEntityCollisionRegistration(
 /// </remarks>
 internal sealed class LiveEntityCollisionBuilder
 {
-    private readonly Func<uint, FlatCollisionSphere?> _physicsBspBounds;
+    private readonly Func<uint, ShadowPartGeometry?> _physicsBspBounds;
     /// <summary>
     /// The dispatch gate, derived from <see cref="_physicsBspBounds"/> so the
     /// two can never disagree (AP-156), and cached once so <see cref="Build"/>
@@ -62,11 +62,13 @@ internal sealed class LiveEntityCollisionBuilder
         : this(
             id =>
             {
-                FlatPhysicsBsp? flat =
-                    physicsData.GetFlatGfxObj(id)?.PhysicsBsp;
+                FlatGfxObjCollisionAsset? asset = physicsData.GetFlatGfxObj(id);
+                FlatPhysicsBsp? flat = asset?.PhysicsBsp;
                 return flat is { RootIndex: >= 0 }
-                    ? flat.Nodes[flat.RootIndex].BoundingSphere
-                    : (FlatCollisionSphere?)null;
+                    ? ShadowPartGeometry.Create(
+                        flat.Nodes[flat.RootIndex].BoundingSphere,
+                        asset!.VisualBounds)
+                    : (ShadowPartGeometry?)null;
             },
             defaultPose)
     {
@@ -74,14 +76,15 @@ internal sealed class LiveEntityCollisionBuilder
     }
 
     /// <param name="physicsBspBounds">The part GfxObj's physics-BSP root
-    /// bounding sphere, or null when it has none. ONE resolver answers both
-    /// questions the builder asks — "does this part dispatch as BSP?" and
-    /// "where and how big is its flood sphere?" — so the dispatch gate and
-    /// the emitted geometry cannot disagree, and the sphere's radius cannot
-    /// be carried while its origin is dropped. That split is what produced
-    /// the AP-156 mis-placed flood.</param>
+    /// bounding sphere AND its authored vertex-array box, or null when it has
+    /// no physics BSP. ONE resolver answers every question the builder asks —
+    /// "does this part dispatch as BSP?", "where and how big is its flood
+    /// sphere?", and "what is its outdoor extent?" — so the dispatch gate and
+    /// the emitted geometry cannot disagree, the sphere's radius cannot be
+    /// carried while its origin is dropped (AP-156), and the outdoor extent
+    /// walk cannot be left without a box (#334).</param>
     internal LiveEntityCollisionBuilder(
-        Func<uint, FlatCollisionSphere?> physicsBspBounds,
+        Func<uint, ShadowPartGeometry?> physicsBspBounds,
         LiveEntityDefaultPoseResolver defaultPose)
     {
         _physicsBspBounds = physicsBspBounds