docs(todo): remove the vehicle blocks that leaked into the hero facade section

A shared heading string made one edit land in two sections, so the hero-facade task carried a copy of the
vehicle's bisect evidence. The section is back to its own two steps.

Also re-ran the gates on the tree as it stands after today's ground and placement work:

  Tools/ue_audit_scene.py  593 mesh actors, every mesh has a material, building X ranges as expected,
                           no duplicate actor labels, 0 failures
  prettier --check         all Markdown clean
  unittest                 99 tests pass

TODO.md

@@ -123,69 +123,6 @@ Deferred rather than guessed. What a fresh session needs:
 
 Split out of `0.3.0` on 2026-11-09 on the owner's instruction: the three hero-facade staging shots (`review-hero-facade-front`, `review-hero-facade-oblique`, `review-hero-portals`) were rejected as "rework needed to match reference", and that is asset work rather than vehicle work.
 
-### Bisect result: the map, not the pawn
-
-The same pawn, unchanged, in two maps:
-
-```
-ReviewMap (flat 160 m floor):  Z 200 -> 188 -> 174 -> 157 -> 87   vZ -208 -> -663   falls correctly
-DemoMap, on the street:        Z 486 -> 920 -> 1126 -> 1385      vZ oscillates ~0  teleports up
-DemoMap, 60 m off the street:  Z 291 -> 467 -> 920 -> 1343       vZ +1595          launches
-DemoMap, 25 m above ground:    Z 2496 -> 2664 -> 3068 -> 3434    vZ +1509          launches at once
-```
-
-**So the Chaos rig is fine and `DemoMap` is what breaks it** - at any height, anywhere in that map, and not by contact (25 m in the air launches immediately). The next comparison is between the two maps' world settings and level actors: `ReviewMap` was built by `Tools/ue_build_review_map.py`, `DemoMap` by `Tools/ue_build_demo_map.py`, and the difference that matters is in what one stages and the other does not.
-
-### The transform is written directly, not moved
-
-Zeroing the body's linear and angular velocity **every frame** for two seconds changes nothing:
-
-```
-t=0.25 Z=3220 vZ=0   t=0.75 Z=3683 vZ=0   t=1.25 Z=4197 vZ=0
-```
-
-The actor keeps rising at ~1200 cm/s while its velocity is pinned to zero. **Something calls a transform setter on the vehicle every frame** - this is not a force, an impulse or a bad initial state, all of which the clamp would have removed.
-
-`Game/GigLine/Source/GigLine/*.cpp` contains exactly one direct transform write outside the character (`GigLineShotActor` moves its camera), so the writer is engine-side: the Chaos vehicle component driving `UpdatedComponent` from a vehicle state that was never created, or a skeletal-mesh transform update.
-
-### Map-content bisect: the terrain is involved
-
-Built `Tools/ue_vehicle_probe_map.py` (duplicates `ReviewMap`, optionally adds ONE demo mesh plus the pawn, saves as `VehicleProbe`) and ran it:
-
-```
-control (no extra mesh)     Z 300 -> 297 over 1.25 s   (resting on the review floor)
-+ Terrain_DEM               Z 300 -> 498 over 1.25 s   (thrown upward)
-```
-
-So `Terrain_DEM` is enough to reproduce it in a map that otherwise works. Two fixes were then tried and **neither helped**:
-
-- `Tools/ue_clear_simple_collision.py` cleared the auto-generated convex hulls from all 76 site/street meshes (terrain had **1 convex element** over the whole 279 m) and set complex-as-simple - still rises.
-- Setting the terrain component to `CollisionEnabled::QueryOnly` so traces still hit it but the physics solver ignores it - still rises.
-
-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.
-
-### 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).
-3. Only after the bisect: fix, then confirm `Wheels.Num() == 4`.
-
 ### Tasks
 
 - [ ] Rebuild the El Capitan hero facade to match the reference photography: cornice depth, the banner proportions, window rhythm, and the three entry portals.