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.

docs/formats/level-wad.md

@@ -117,13 +117,15 @@ not yet identified.
 
 ## Not yet parsed
 
-- **`data`** — the geometry. This is the next target and where the visible
-  level comes from: tfrag terrain, tie instances, shrub foliage, moby classes,
-  sky shells and textures.
-- **`gameplay`** — begins `WAD` + a per-level id byte + a count, and behaves
-  like an LZ77 stream but does **not** decode with the WAD decoder (all 27
-  levels fail with "adjacent literal packets", which the format forbids). It is
-  a different compression, or a different framing. Recorded in
+- **`data`** — the geometry. Parsed through
+  [`level-data.md`](level-data.md); `core_index`, `gs_ram` and `core_data` are
+  read, and `core_data` decompresses.
+- **`gameplay`** — a WAD LZ77 stream, exactly like `core_data`, and it
+  decompresses. The magic is `WADy\r\n`: byte 3 is `0x79` on level 0 rather
+  than `0x0d`, which reads as a per-level variation but is just part of the
+  32-bit little-endian stream length. Decompressed it holds the level's light
+  bank — 5 directional light sets on level 0. The earlier reading of "not a
+  WAD" came from parsing the *compressed* bytes; see
   [`../plan/level-assets.md`](../plan/level-assets.md).
 - **`sound_bank`** — begins with `SBlk` at `+24` and `DAW` at `+36`; both
   signatures are present in all 27 levels.