Initialise native Rust port of Ratchet & Clank: Going Commando

Sets up the foundation for reimplementing the PS2 game in Rust rather than
emulating it. Nothing is implemented yet; this is the scaffold, the verified
target and the working agreements that keep a long project coherent.

Target disc, verified against a real image:

  SCUS_972.68 v1.01, USA Black Label, NTSC 60 Hz
  boot ELF 2,618,684 bytes, SHA-1 bacda860...d098a77, entry 0x00131AE8

The entry point independently matches the value recorded by the rac2-gc-decomp
community reference, which cross-confirms the identification. This is the exact
build the upstream research pins; Greatest Hits v2.00 is a different binary and
is not the target. NTSC matters beyond label compatibility: PAL discs run 50 Hz,
which would make chargeboots and other speed-sensitive movement run at 5/6
speed. Verifying the disc before writing movement code avoids discovering that
in Phase 5.

Contents:

- Five-crate workspace (formats, extract, game, video, engine) on Bevy 0.19.1,
  matching the version ReRAC uses so its Graphics Synthesizer and VU work stays
  portable. `cargo check --workspace` is clean.

- tools/identify-disc.py, which reproduces the identification against any
  disc image and distinguishes a truncated dump from a non-PS2 image.

- .githooks/pre-commit, refusing game data from entering git history: disc
  image extensions, asset directories, container signatures at offset 0, and
  files over 50 MiB. Verified against seven cases including a disc image
  renamed to look like source. Now that this pushes to a remote, this matters
  more than it would have locally.

- AGENTS.md, the operating agreements: no game data ever, reproduce the PS2
  float model rather than approximating it, bound every read, verify against
  the real disc.

- PROVENANCE.md, recording that this follows ReRAC (ISC) and learns from
  rac2-gc-decomp (MIT). Wrench is used as a written specification only and no
  GPLv3 code is copied, since that would relicense everything derived from it.
  RAC2Decomp is explicitly not used: its provenance is disputed in the upstream
  community reference, and it targets the wrong region.

- docs/roadmap.md, phased so the riskiest unknowns are retired early. The two
  that matter: overlay relocation transfers from ReRAC and makes 27 level
  overlays tractable, while VU1 microcode is binary and is the hardest single
  item. Phase 5 is a deliberately scoped Veldin vertical slice as the go/no-go.

docs/disc-identification.md

@@ -0,0 +1,87 @@
+# Disc identification — VERIFIED 2026-10-09
+
+Your disc was identified while initialising this repository. It is the **best
+case target**: the exact build that `OpenRAC/rac2-gc-decomp` pins.
+
+## Result
+
+| Field | Value |
+|---|---|
+| Title | Ratchet & Clank: Going Commando |
+| Serial | `SCUS_972.68` |
+| Version | **1.01** (Black Label) |
+| Video mode | **NTSC** (60 Hz) |
+| Region | USA |
+| ISO 9660 volume | `RATCHETANDCLANK2` |
+| Image size | 3,828,350,976 bytes |
+| Publisher / Preparer | SONY / INSOMNIAC |
+
+### Boot executable (`SCUS_972.68`)
+
+| Property | Value |
+|---|---|
+| Size | 2,618,684 bytes |
+| SHA-1 | `bacda860cbd6723142e86db56f197e47e728970f` |
+| CRC-32 | `262705496` |
+| Format | ELF32, little-endian, MIPS (EM_MIPS = 8) |
+| Entry point | `0x00131AE8` |
+
+The entry point `0x00131AE8` matches the value independently recorded by the
+`rac2-gc-decomp` community reference for this target, which cross-confirms the
+identification.
+
+## Why this matters
+
+**`VER = 1.01` + `VMODE = NTSC` is exactly what we want.**
+
+- **v1.01 is the pinned target.** `rac2-gc-decomp` states plainly that
+  *Greatest Hits v2.00 is a different target — do not point a build at it.*
+  You have the Black Label original.
+- **NTSC means 60 Hz.** This is the detail that decides the movement constants.
+  PAL discs report `VMODE = PAL` and run the game at 50 Hz, which makes the
+  chargeboots and other speed-sensitive movement run at 5/6 of their intended
+  speed. Building against NTSC timing constants is correct for this disc.
+
+There is no ambiguity to resolve, so no disc-conversion work is required.
+
+## Not used for identification
+
+Redump's catalogue records the **first track** hash for this disc as
+`f2cfaf0eb12b3c0d8fd6db7aa49ce032e8a6020b` (CRC-32 `3828350976`). The values
+computed above are the **boot executable's** hash, which is a different thing:
+a single file rather than a track. Both are stable identifiers, but they must
+not be compared against each other. We identify by serial + `VER` + `VMODE` +
+boot-ELF SHA-1, which is unambiguous.
+
+## Disc layout (observed)
+
+R&C2 lists its assets in the ISO 9660 filesystem, unlike R&C1. Confirmed
+entries at the disc root:
+
+```
+SYSTEM.CNF        60 bytes
+RC2.HDR        408,444     <- the table of contents, as a named file
+SCUS_972.68  2,618,684     <- the boot ELF
+IOPRP255.IMG   264,449
+Z6TAIL.DUP           0
+G/...                    <- global WADs (LEVEL*, AUDIO*, SCENE*, MPEG*, HUD, …)
+```
+
+`RC2.HDR` being present as a real file is convenient: the extractor can read
+the table of contents directly instead of hunting for it at a fixed sector as
+with R&C1. The `G/` WADs are listed in the filesystem, so enumeration works
+too.
+
+### Observation on MPEG WADs
+
+The three MPEG WADs are large — roughly 1.0 GB, 1.3 GB and 115 MB. That is a
+substantial fraction of the 3.8 GB disc and will matter for the video phase
+(R&C2 uses IPU/FMV streams, notably the title screen). Worth factoring into the
+plan: video is a large *data* problem before it is a decoding problem.
+
+## Reproducing this check
+
+`tools/identify-disc.py` performs the same identification against any
+R&C2 disc image and prints the table above. It reads only the ISO 9660
+structures, `SYSTEM.CNF` and the boot ELF (a few MB of seeks), so it runs in
+well under a second on a local image.