Consolidate: tidy level.rs, correct stale docs, pin hardware models

No behaviour change. This is the pass over the last stretch of work to
make sure the accumulated result hangs together rather than only each
commit in isolation.

Code. lit_color had grown a `let _ = (depth, lod_distances)` and a dead
branch from repeated edits. The directional pass genuinely does not
depend on distance, so the parameters are gone rather than discarded,
with a note that the point lights -- not implemented -- will need them.
lit_at folded into lit_color, which had become a wrapper around it.
Checked for leftover scaffolding: only two env vars remain, both real
(GC_ENGINE_SHOT and GC_ENGINE_DEBUG_BOUNDS); GC_ENGINE_UNLIT,
GC_ENGINE_DEBUG_COLOR and GC_ENGINE_ABL were never actually written,
because those edits silently failed to apply against rustfmt'd source.

AGENTS.md. The crate table did not say that gc-engine owns hardware
models. ps2.rs is the Emotion Engine's FPU and the lighting pass runs
on it, so the boundary is now stated: gc-formats decodes inputs,
gc-engine reproduces how the hardware computes with them. That is the
distinction rule 2 depends on, and it was implicit.

Docs. Three claims had been overtaken by what we learned and were
actively misleading:

* docs/formats/level-wad.md still said gameplay "does not decode with
  the WAD decoder". It does; it is a WAD stream.
* docs/plan/level-assets.md carried a whole section, "a compression we
  have not identified", with a ruled-out list including "bit order",
  "header length" and "the WAD format at all". All three were ruled out
  against the wrong input. Replaced, with the failure mode kept: a
  uniform failure across 27 inputs was read as "the decoder is wrong"
  when it meant "the data was handed over uncompressed", and the
  positive control -- decompress and look -- was never run.
* The same file still said the tfrag "record framing is not recovered".
  True, but it was a false lead that has since been superseded by the
  VIF1 framing. Kept as a recorded wrong turn rather than deleted.

Also refreshed "Still open" to name what is actually outstanding:
point lights, the GS register set, the guard-band clip test, the
unread core_index class tables, and -- stated plainly -- that lighting
magnitudes are unverified because there is still nothing to compare
against.

Verified after the changes: 148 tests pass, clippy and fmt clean, all
5,213 extracted files match the hash table, and level 0 still loads at
26,758 triangles with the same LOD split and fully lit.

AGENTS.md

@@ -77,13 +77,20 @@ Read these before working in an unfamiliar area:
 | `gc-extract` | Disc pipeline: identify, unpack, verify. |
 | `gc-game` | Game logic: hero, weapons, classes, progression, saves. |
 | `gc-video` | IPU/MPEG-2 decode. |
-| `gc-engine` | Bevy app: GS, VU0/VU1, renderer, frame loop. |
+| `gc-engine` | Bevy app: GS, VU0/VU1, renderer, frame loop. Also owns the **hardware models** — `ps2.rs` is the Emotion Engine's FPU, and the tfrag lighting pass runs on it. |
 
 The dependency direction is `gc-formats` ← `gc-extract`; `gc-formats` ←
 `gc-game` ← `gc-engine`; `gc-video` ← `gc-game` ← `gc-engine`. `gc-formats`
 depends on nothing of ours. Do not invert these — a format parser that can
 reach into the engine cannot be tested in isolation.
 
+A hardware model belongs in `gc-engine`, not `gc-formats`. `gc-formats`
+decodes *inputs* — including the data a hardware model consumes, such as the
+overlay's sine table — but arithmetic that reproduces how the PS2 computes
+something is an engine concern. `tfrag_light.rs` (formats) holds the normal
+table and the light bank framing; `tfrag_light.rs` (engine) holds the pass
+that uses them.
+
 ## Conventions
 
 - Rust 2021 edition, workspace inheritance for all shared config. Do not