refactor(tools): group the sixty scripts by what they talk to

One directory with sixty scripts stopped being navigable, and the grouping is also the sandbox boundary:

  Tools/unreal/    commandlets and the two map builders, with ue_common.py and ue_placement.py as the
                   shared imports (they need the engine)
  Tools/blender/   builders, exporters, the FBX preset, the MPFB character pipeline, blender_screenshots
                   (they need the Blender Flatpak)
  Tools/review/    the visual loop: render_screenshots.sh, judge_screenshot.py, hero_compare.py,
                   build_comparison_md.py, e2e_asset_check.py, hero_iterate.sh, visual_loop.py,
                   visual_targets.json
  Tools/gen/       image and texture generation: the ComfyUI driver, deterministic texture writers,
                   reference fetching
  Tools/input/     OS-level input injection
  root             _common.py, check-lfs.sh, addon_compat_probe.py, sibling_asset_audit.py, tests/

Every moved script now resolves the repository root as ../.. and puts the tools root plus its siblings on
sys.path, so 'import ue_common' still works from unreal/. The test suite bootstrap does the same for the five
folders. render_screenshots.sh takes the folder as a third argument to run_cmdlet, and the e2e driver,
hero_iterate.sh and the comparison generator were repointed.

51 README rows now link to their new location, the README gains a Layout section naming each folder's
sandbox, and the architecture notes and Blender README follow the moves.

Verified: 108 tests pass, prettier is clean, judge_screenshot.py and hero_compare.py run from their new
homes, and the e2e run was aborted mid-way (it had been rebuilding an empty DemoMap for 15 minutes) and is
being rerun against the new layout.

TODO.md

@@ -61,7 +61,7 @@ DemoMap, 60 m off the street:  Z 291 -> 467 -> 920 -> 1343       vZ +1595
 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.
+**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/unreal/ue_build_review_map.py`, `DemoMap` by `Tools/unreal/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
 
@@ -77,7 +77,7 @@ The actor keeps rising at ~1200 cm/s while its velocity is pinned to zero. **Som
 
 ### 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:
+Built `Tools/unreal/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)
@@ -86,7 +86,7 @@ control (no extra mesh)     Z 300 -> 297 over 1.25 s   (resting on the review fl
 
 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.
+- `Tools/unreal/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.
@@ -103,7 +103,7 @@ The pawn still rises in every case, so the fault is not the terrain's convex hul
 
 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 probe workflow is in place: `Tools/unreal/ue_vehicle_probe_map.py` with `GIGLINE_PROBE_ASSET` and `GIGLINE_PROBE_NOCOLLISION`, `Tools/unreal/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.
 
@@ -152,7 +152,7 @@ imported mesh bounds y = -13 .. +1250 cm
 
 The facade's detail - banners, and by the same construction the window bays and portal surrounds - is placed **behind** the wall's front face, so it is inside `Hero_Mass` and never renders. That is why the captures show a plain block with six columns: the columns, cornice and dentils happen to protrude, everything else does not. The model does not need remodelling first; its detail needs moving in front of the wall.
 
-**Fix:** give `Tools/hero_facade_build.py` a `FRONT_Y = -BODY_D / 2.0 - 0.5` constant (the mass's front face) and place every elevation detail relative to it (`FRONT_Y - 0.10` for applied detail, `FRONT_Y` for flush), instead of the hand-typed negative coordinates each call site uses now. Then re-export, re-import and re-render.
+**Fix:** give `Tools/blender/hero_facade_build.py` a `FRONT_Y = -BODY_D / 2.0 - 0.5` constant (the mass's front face) and place every elevation detail relative to it (`FRONT_Y - 0.10` for applied detail, `FRONT_Y` for flush), instead of the hand-typed negative coordinates each call site uses now. Then re-export, re-import and re-render.
 
 **And check the review shot.** The three hero captures show a plain block with six columns and nothing else - no banners, no windows, no portals - while the mesh demonstrably carries all four materials (`M_Facade_Banner`, `M_Facade_Stone`, `M_Facade_StoneShadow`, `M_Facade_GlassDark`) and is staged at `(-13336, 1307, 0)` with yaw 0. That suggests the cameras are framing the wrong actor (`Frontage_SM_ElCapitanTheatre` sits at the origin) or the wrong side, and the "rework" note may be describing a camera error rather than the model. Verify that first: one render with a camera aimed at `Hero_Facade` from Y -4000 at 8 m height.
 
@@ -171,7 +171,7 @@ Still missing, from the same references: warm sandstone instead of the flat pale
 
 ### The iteration loop
 
-`bash Tools/hero_iterate.sh` runs the whole chain in one command: chmod the Blender files, build the facade, import it, render the capture set, judge the shot with the vision model, and write a comparison plate at `Screenshots/review/hero-compare-front.png`. Each step fails loudly and logs to `/tmp/gigline/`.
+`bash Tools/review/hero_iterate.sh` runs the whole chain in one command: chmod the Blender files, build the facade, import it, render the capture set, judge the shot with the vision model, and write a comparison plate at `Screenshots/review/hero-compare-front.png`. Each step fails loudly and logs to `/tmp/gigline/`.
 
 Iteration 1 verdict (judge, confidence 0.9):
 
@@ -181,7 +181,7 @@ Measured against the plate, that splits into:
 
 | Finding | Reality | Next action |
 | --- | --- | --- |
-| not warm sandstone | true - the UE material `M_FacadeStone` is still near-white (0.62-0.76 grey) | warm the UE material spec in `Tools/ue_hero_facade_import.py`, not the Blender one |
+| not warm sandstone | true - the UE material `M_FacadeStone` is still near-white (0.62-0.76 grey) | warm the UE material spec in `Tools/unreal/ue_hero_facade_import.py`, not the Blender one |
 | fluting missing | false - 120 flute strips exist and cast shadows; they are lost at 45 m | not a modelling problem; check the review camera distance |
 | banners wrong | partly - proportions are now 1.35 x 6.2 m and hang correctly, the lettering is absent | needs a texture, not geometry |
 | no doorways | false - three 1.2 m deep recesses with steps; they read dark because the reveal is glass-black | lighten the reveal material |
@@ -199,7 +199,7 @@ Measured against the plate, that splits into:
 
 ### Vehicle production - active - session-5598ce7e-27e3-4c64-bb49-c04a4a31ee58 (branch `vehicle-0.3.0`)
 
-- [A] Model one vehicle in Blender with collision meshes; export to Unreal. **Model done** (`Tools/vehicle_build.py` → `Art/blender/vehicle/gigline-sedan.blend`, preview in `Art/blender/vehicle/preview.png`): 4.72 x 1.80 x 1.44 m, 2.78 m wheelbase, 1.62 m track, 0.33 m wheels, 252 triangles, four `UCX_` convex hulls. Dimensions come from real sedan figures and are logged to the report, so the vehicle config can read them rather than restating them. - **Imported into Unreal** (`Tools/ue_vehicle_import.py` → `/Game/Hollywood/Vehicle`), split per the vehicle-artist object split: `SM_Vehicle_Body` (3 slots, 4.76 x 1.76 x 1.28 m), `SM_Vehicle_Glass`, `SM_Vehicle_Light_Front`, `SM_Vehicle_Light_Rear`, `SM_Vehicle_Mirrors`, and one `SM_Vehicle_Wheel` (0.22 x 0.66 x 0.66 m) reused four times. The body FBX carries the `UCX_` hulls as simple collision.
+- [A] Model one vehicle in Blender with collision meshes; export to Unreal. **Model done** (`Tools/blender/vehicle_build.py` → `Art/blender/vehicle/gigline-sedan.blend`, preview in `Art/blender/vehicle/preview.png`): 4.72 x 1.80 x 1.44 m, 2.78 m wheelbase, 1.62 m track, 0.33 m wheels, 252 triangles, four `UCX_` convex hulls. Dimensions come from real sedan figures and are logged to the report, so the vehicle config can read them rather than restating them. - **Imported into Unreal** (`Tools/unreal/ue_vehicle_import.py` → `/Game/Hollywood/Vehicle`), split per the vehicle-artist object split: `SM_Vehicle_Body` (3 slots, 4.76 x 1.76 x 1.28 m), `SM_Vehicle_Glass`, `SM_Vehicle_Light_Front`, `SM_Vehicle_Light_Rear`, `SM_Vehicle_Mirrors`, and one `SM_Vehicle_Wheel` (0.22 x 0.66 x 0.66 m) reused four times. The body FBX carries the `UCX_` hulls as simple collision.
   - **LODs cut for real:** decimating the duplicate gives LOD1 at 38 triangles and LOD2 at 14, against 132 for LOD0. The first attempt duplicated the shell unchanged and produced 84-triangle LODs that saved nothing - worth remembering as the failure mode of a "LOD" step nobody measures.
   - **LOD group wiring is open:** `StaticMeshEditorSubsystem.import_lod` is unavailable in a headless commandlet (`get_editor_subsystem` returns None), so the LOD meshes import as their own assets and the group still needs an editor session.
 - [~] Set up Chaos Vehicle with wheel and physics configuration. **It sits on the road now; it does not drive yet.**
@@ -207,7 +207,7 @@ Measured against the plate, that splits into:
   - **Drive test fails, with a specific cause:** `-drivetest` holds full throttle for 3 s and reports speed and distance. Result: `speed=0 cm/s, travelled 2.2 m -> FAIL`, and BeginPlay logs **`0 wheel objects after register`** while the component reports 4 wheel setups. The setups exist but no wheels are created from them, so there is nothing to apply torque to.
   - **Next:** confirm the skeleton's bone names match the setups (`Wheel_FL`, `Wheel_FR`, `Wheel_RL`, `Wheel_RR`) - a name mismatch silently produces zero wheels - and give the front and rear pairs their own `UChaosVehicleWheel` subclasses rather than the base class, which is what the setups point at today.
   - **Also open:** LOD group wiring, enter/exit, driving route, handling.
-- [x] Fix the vehicle not rendering in the scene. **Chased to a strong clue, not yet solved.** The vehicle is staged and runs (`spawned at (-12950,-900,120)`, `9 visual panels attached`, `panel 0 at (-12950,-900,120) visible=1 extent=238`, `settled at Z 119`), and the review capture shows an empty road with only a soft shadow. `Tools/visual_loop.py --verify` passes the frame; `Tools/judge_screenshot.py` returns `verdict=no confidence=1.0`. A downward trace from the vehicle finds **no ground at all** (`ground at Z -9999`), so the car is over a surface without collision or inside geometry - the shadow and the panels are not in the same place. **Fixed 2026-11-09** — the car renders, built from the owner's `hot hatch.blend`. **Fixed:** the vehicle was spawned 2.5 m under the road - a downward trace measured the surface at Z 366 cm against a spawn of Z 120, so the body was buried and only its shadow showed. The spawn is now Z 470 and it settles there.
+- [x] Fix the vehicle not rendering in the scene. **Chased to a strong clue, not yet solved.** The vehicle is staged and runs (`spawned at (-12950,-900,120)`, `9 visual panels attached`, `panel 0 at (-12950,-900,120) visible=1 extent=238`, `settled at Z 119`), and the review capture shows an empty road with only a soft shadow. `Tools/review/visual_loop.py --verify` passes the frame; `Tools/review/judge_screenshot.py` returns `verdict=no confidence=1.0`. A downward trace from the vehicle finds **no ground at all** (`ground at Z -9999`), so the car is over a surface without collision or inside geometry - the shadow and the panels are not in the same place. **Fixed 2026-11-09** — the car renders, built from the owner's `hot hatch.blend`. **Fixed:** the vehicle was spawned 2.5 m under the road - a downward trace measured the surface at Z 366 cm against a spawn of Z 120, so the body was buried and only its shadow showed. The spawn is now Z 470 and it settles there.
   - **Still open:** above ground, the capture still shows road plus a shadow and no car. Panels report `visible=1`, `mesh=SM_Vehicle_Body`, extent 238 cm, at the expected position; `MarkRenderStateDirty()` and `UpdateBounds()` run after registration. Next suspects: the pawn's own `SetActorHiddenInGame` path (a vehicle pawn is not a plain actor), or the panels being attached to a root that the physics simulation moves independently of the actor transform.
 - [x] Fix the character and car floating. **The measurement was taken at the wrong moment.** The foot probe ran in `BeginPlay`, while the pawn is still at its spawn height and falling, so every trace reported a surface far below it (`ground 366` against an actor at 561) and read as a float that was not there. The probe now runs **three seconds after spawn**, from the capsule's feet, on three channels, and names the actor it hits. Character: the player start at Z 600 left the soles 39 cm in the air (the capsule settles at 561 on this pavement); the start is now the measured 561. Car: the template's lowest geometry is exhaust, so grounding on the whole model put the tyres 4 cm above the origin - it is now grounded on its wheels, staged at Z 342 after the traced road height (366) disagreed with the visible road by ~25 cm.
 - [x] Fix the vehicle's material colour. The template's `car paint` is a legacy mix-shader graph that the FBX exporter cannot map, so `SM_Vehicle_Body` imported holding `WorldGridMaterial` and rendered black while Blender showed red. Legacy graphs are now converted to Principled before export (saturated colour wins over the grey diffuse next to it), and the staged body panel is assigned `M_Vehicle_HatchPaint`. Judge: `verdict=yes confidence=0.9`.