test(vehicle): collision is not the cause either - defer the rig to its own session

Third fix tried and failed: the terrain staged in the probe map with collision disabled entirely. The pawn
still rises (Z 315 -> 421), exactly as with collision enabled.

With that, the terrain's convex hull, its collision channel and its collision itself are all eliminated, and
the failure survives in a map whose only difference is the presence of a 279 m static mesh.

The player is unaffected throughout - re-checked after every attempt, still standing on Sidewalk_North_07
at 157 cm - so nothing in the walkable demo regressed.

Deferred rather than guessed, per AGENTS.md: the task is marked deferred with the three failed fixes, the
probe workflow and switches a fresh session inherits, and the next question framed precisely - why a map
containing a collisionless 279 m static mesh changes a physics body's behaviour, which points at streaming,
memory layout or the broadphase rather than at collision authoring.

Generated probe levels deleted; the tools stay.

TODO.md

@@ -91,7 +91,23 @@ So `Terrain_DEM` is enough to reproduce it in a map that otherwise works. Two fi
 
 That means the ejection is not the convex hull and not the collision channel; the next probe is whether it is the _complex_ triangles (inverted winding pushing bodies out) - test by setting `Terrain_DEM` to **no collision at all** in the probe map and confirming the pawn falls.
 
-### Bisect plan for the next pass
+### Where it stands: deferred to its own session
+
+Three fixes were tried after the terrain bisect and **none changed the behaviour**:
+
+1. clearing the auto-generated convex hulls from all 76 site/street meshes;
+2. setting the terrain component to `QueryOnly`;
+3. staging the terrain in the probe map with **collision disabled entirely**.
+
+The pawn still rises in every case, so the fault is not the terrain's convex hull, not its collision channel, and not even its collision. The player is unaffected throughout - re-checked after each fix, and the character still stands on `Sidewalk_North_07` at 157 cm.
+
+Deferred rather than guessed. What a fresh session needs:
+
+- the probe workflow is in place: `Tools/ue_vehicle_probe_map.py` with `GIGLINE_PROBE_ASSET` and `GIGLINE_PROBE_NOCOLLISION`, `Tools/ue_clear_simple_collision.py` for the hull hygiene;
+- the vehicle diagnostics are switches: `-probes`, `-profile`, `-novehmover`, plus the always-on velocity clamp, overlap list and velocity profile;
+- the next question is _why a map carrying a 279 m static mesh changes a physics body's behaviour when that mesh has no collision at all_, which points at streaming, memory layout or the physics scene's broadphase rather than at collision authoring.
+
+### Bisect plan (kept for the next session)
 
 1. Spawn the same pawn in `ReviewMap` (flat 160 m floor, no slices, no UCX ground) and repeat the profile. Flies there too -> the asset/component is at fault. Settles there -> something in `DemoMap` (the UCS slabs, the terrain, or the world settings) drives it.
 2. In parallel, spawn a stock `AWheeledVehiclePawn` with `SK_Vehicle_Sedan` and default settings in the same spot: if the stock pawn settles, the difference is in `AGigLineVehicle`'s setup (mass override, stability control, our movement subclass).
@@ -99,7 +115,7 @@ That means the ejection is not the convex hull and not the collision channel; th
 
 ### Tasks
 
-- [ ] Give `SK_Vehicle_Sedan` a physics asset whose single chassis body matches the car's box and is positioned below the shell, then confirm the pawn settles on the road instead of launching.
+- [D] Give `SK_Vehicle_Sedan` a physics asset whose single chassis body matches the car's box and is positioned below the shell, then confirm the pawn settles on the road instead of launching.
 - [ ] Confirm `Wheels.Num()` becomes 4 once the vehicle is created; log it at the settle check.
 - [ ] Only then re-stage the pawn, re-add enter/exit and the driving route.
 
@@ -148,7 +164,23 @@ So `Terrain_DEM` is enough to reproduce it in a map that otherwise works. Two fi
 
 That means the ejection is not the convex hull and not the collision channel; the next probe is whether it is the _complex_ triangles (inverted winding pushing bodies out) - test by setting `Terrain_DEM` to **no collision at all** in the probe map and confirming the pawn falls.
 
-### Bisect plan for the next pass
+### Where it stands: deferred to its own session
+
+Three fixes were tried after the terrain bisect and **none changed the behaviour**:
+
+1. clearing the auto-generated convex hulls from all 76 site/street meshes;
+2. setting the terrain component to `QueryOnly`;
+3. staging the terrain in the probe map with **collision disabled entirely**.
+
+The pawn still rises in every case, so the fault is not the terrain's convex hull, not its collision channel, and not even its collision. The player is unaffected throughout - re-checked after each fix, and the character still stands on `Sidewalk_North_07` at 157 cm.
+
+Deferred rather than guessed. What a fresh session needs:
+
+- the probe workflow is in place: `Tools/ue_vehicle_probe_map.py` with `GIGLINE_PROBE_ASSET` and `GIGLINE_PROBE_NOCOLLISION`, `Tools/ue_clear_simple_collision.py` for the hull hygiene;
+- the vehicle diagnostics are switches: `-probes`, `-profile`, `-novehmover`, plus the always-on velocity clamp, overlap list and velocity profile;
+- the next question is _why a map carrying a 279 m static mesh changes a physics body's behaviour when that mesh has no collision at all_, which points at streaming, memory layout or the physics scene's broadphase rather than at collision authoring.
+
+### Bisect plan (kept for the next session)
 
 1. Spawn the same pawn in `ReviewMap` (flat 160 m floor, no slices, no UCX ground) and repeat the profile. Flies there too -> the asset/component is at fault. Settles there -> something in `DemoMap` (the UCS slabs, the terrain, or the world settings) drives it.
 2. In parallel, spawn a stock `AWheeledVehiclePawn` with `SK_Vehicle_Sedan` and default settings in the same spot: if the stock pawn settles, the difference is in `AGigLineVehicle`'s setup (mass override, stability control, our movement subclass).