docs(vehicle): evidence, ruled-out list and three ordered suspects

The previous edit to this section never applied - a substring that no longer existed - so the task
still described only the first launch observation. It now records everything measured this session:

  box 452x205x40 centre 0,0,-18 | bounds extent 1,1,1
  velocity -24,-182,-28 cm/s | mass 1500 | sim=1 | setups=4 wheels=0

The conclusion is that the body is nearly still while the actor is nine metres up, so this is a
transform problem rather than a force one, and the suspects are ordered: the component hierarchy, the
Chaos movement component's transform updates, and then the skeletal mesh's bone layout - which would
explain CreateVehicle() bailing before it ever builds wheels.

Ruled out with a run each: spawn penetration at four heights, panel collision, chassis box dimensions,
world gravity, and mass.

TODO.md

@@ -16,12 +16,27 @@ Split out of `0.3.0` because it is a physics problem, not an asset one. **The Ch
 ### Evidence
 
 ```
-GigLine vehicle: 0 wheel objects once physics exists
-GigLine vehicle: ground at Z 150 cm, actor 1993 cm, height above ground 1843 cm
-GigLine vehicle: settled at Z 1993 cm, simulating=1, speed=0 cm/s
+GigLine vehicle geometry: box 452x205x40 centre 0,0,-18 | bounds origin ...,1393 extent 1,1,1
+GigLine vehicle motion:   velocity -24,-182,-28 cm/s  angular ~0  mass 1500  sim=1
+GigLine vehicle mesh asset: SK_Vehicle_Sedan
+GigLine vehicle diag:     mesh=1 simulating=1 physasset=yes setups=4 wheels=0
 ```
 
-Wheels are created in `CreateVehicle()` only when the physics state produced a vehicle, so the chassis body itself is the suspect: `PA_Vehicle_Sedan` carries one box on the `root` bone, and the skeletal mesh is `SK_Vehicle_Sedan`. A vehicle pawn that launches itself upward usually has a body that starts intersecting geometry, or a physics asset whose body sits at the origin rather than under the car.
+**The physics body is nearly still while the actor is nine metres above its spawn.** That is not a force problem, it is a transform problem: something writes the actor transform that is neither the body's velocity nor our code. The mesh component's bounds read `extent 1,1,1` - a degenerate 1 cm box - which is the same symptom seen from the other side.
+
+### Ruled out (each tested in its own run)
+
+- **Spawn penetration** - spawned level with the road, 1.2 m above it, 3 m above it and 5 m above it; the actor climbs in every case.
+- **Visual panel collision** - disabling it changed nothing.
+- **Wrong chassis box** - `452x205x40 centre 0,0,-18` is the car.
+- **Gravity** - `global_gravity_z = 0.0` and the character falls normally, so the world pulls down.
+- **Mass** - the 1500 kg override applies (logged), and the body still does not rise.
+
+### Suspects, in order
+
+1. **Component hierarchy**: a pawn whose root is the mesh while the physics state belongs to another component behaves exactly like this - correct box, correct mass, near-zero velocity, moving actor, 1 cm bounds.
+2. **`UChaosWheeledVehicleMovementComponent::UpdateState` / `OnUpdateTransform`** writing the transform from a vehicle state that was never created (which is also why `CreateVehicle()` yields no wheels).
+3. **The skeletal mesh asset itself** - `SK_Vehicle_Sedan` came from our own FBX pipeline; if its bone layout does not match what the wheel setups name, `CreateVehicle()` bails before creating wheels.
 
 ### Tasks