docs(vehicle): the visual and physics bodies are different vehicles

SM_Vehicle_Body (hot hatch) is 150x400x122 (length along Y); SK_Vehicle_Sedan is
476x228x144 (length along X). They are built by different scripts and do not share
a forward axis - the likely real cause of the reverse drive. MaxTorque sign was
also a no-op. Next: reconcile the two meshes into one asset with one forward axis.

MEMORY.md

@@ -1117,3 +1117,18 @@ Historical task context from 2026-11-09/10; later vehicle findings above may sup
   authoring is irrelevant. The inversion is in the **engine-torque / drive-force sign** (`FSimpleWheel`),
   not the assets. Next: check `GetEngineTorque()` sign, or override `SetupVehicle`/`ProcessMechanicalSimulation`
   in `UGigLineVehicleMovement` to negate the drive torque.
+
+## 2026-11-10 — Vehicle: the visual body and the physics body are different vehicles
+
+- `SM_Vehicle_Body` (the owner's **hot hatch** template, what the panels render) imports with
+  bounds **150 x 400 x 122 cm** — its length is along **Y**. `SK_Vehicle_Sedan` (the procedural
+  sedan that the Chaos solver drives) is **476 x 228 x 144** with the length along **X**. They
+  are built by different scripts (`vehicle_from_template.py` vs `vehicle_build.py`) and do not
+  even share a forward axis.
+- This is almost certainly the real story behind the "reverse" drive: the solver applies the
+  drive force forward on the skeletal sedan (+X) while the visible car's nose is on a different
+  axis, so a forward physics motion reads as a sideways/backward car. `MaxTorque = -500` was also
+  a no-op (the torque curve normalises the magnitude), ruling out the engine torque sign.
+- Next step is not more solver tracing: reconcile the two meshes — drive the **hot hatch** (make
+  it skeletal, or rebuild `SK_Vehicle_Sedan` to match the hot hatch's axis and dimensions) so the
+  visible and physics cars are one asset with one forward axis.