Implement the PS2 float model and the LightTfrags pass

Two pieces, and the first is the reason the second can be trusted.

ps2.rs is the EE's FPU on raw u32 bit patterns. It is not f32: there are
no denormals (exponent 0 *is* zero), no NaN and no infinity (exponent 255
is an ordinary value, so MAX reads back in Rust as NaN -- a test asserts
exactly that, because it is the sharpest available statement of why this
module exists), every result truncates toward zero, the adder discards
the small operand's bits more than one below the large one's LSB and
returns the large operand unchanged across a 25-bit exponent gap, and
rsqrt is sqrt-then-divide with truncation between the steps rather than
one rounded operation. The lighting pass accumulates all of these across
every vertex of every patch, so this is a visible difference rather than
a rounding curiosity.

tfrag_light.rs is the pass itself: PEXT5 base colour, the select word
picking one light set or blending two by bits 8..15 / 256, blended
directions re-normalised where unblended ones are not, and
base + A.rgb*max(dA, dA*wA) + B.rgb*max(dB, dB*wB). Lighting indexes
positions, not vertex-info entries, since a common entry and a LOD entry
can share a position.

TfragLight gains a `select` field for the u16 at +6. It was briefly
reconstructed with an unsafe pointer cast over the struct, which is
exactly the sort of thing that breaks silently the moment a field is
reordered; it is now a plainly parsed field.

The pass does not run yet. The light bank framing the reference uses --
a u32 offset at +0x04, an i32 count there -- gives offset 0xa0d and a
count of 698810368 on RAC2 level 0, so RAC2's gameplay extent is not
laid out that way. The renderer now counts the vertices it actually lit
and prints it, because falling back silently to the stored colours
produces a plausible but wrong picture:

  lighting: 0 of 80274 vertices shaded by LightTfrags; the rest fall
  back to the tfrag's stored colours (no usable light bank)

That line is the current honest state, and the frame has not changed as
a result. Where RAC2 keeps its light bank is the open question.

crates/gc-formats/src/tfrag.rs

@@ -615,10 +615,29 @@ pub struct TfragLight {
     pub azimuth: i8,
     /// Normal elevation, as an index into the same table.
     pub elevation: i8,
+    /// Base colour as 5:5:5:1.
     pub color: i16,
+    /// Light-set select. Bits 8..15 clear means "use set bits 0..3"; otherwise
+    /// set bits 0..3 is blended with set bits 4..7 by `bits 8..15 / 256`.
+    pub select: u16,
 }
 
 impl TfragLight {
+    /// The light-set select word at +6 of the record.
+    ///
+    /// The parsed struct exposes bytes 0..6; the select is the `u16` that
+    /// follows `color`, so it is read from the record rather than stored as its
+    /// own field.
+    pub fn select(&self) -> u16 {
+        let b = unsafe {
+            std::slice::from_raw_parts(
+                self as *const TfragLight as *const u8,
+                std::mem::size_of::<TfragLight>(),
+            )
+        };
+        u16::from_le_bytes([b[6], b[7]])
+    }
+
     /// Azimuth as the unsigned table index. The field is stored signed but
     /// indexes 0..=255, so the byte is what matters, not its sign.
     pub fn azimuth_index(&self) -> u8 {
@@ -960,6 +979,7 @@ fn read_lights(block: &[u8], at: usize, count: usize) -> Result<Vec<TfragLight>>
             azimuth: block[i + 2] as i8,
             elevation: block[i + 3] as i8,
             color: i16::from_le_bytes([block[i + 4], block[i + 5]]),
+            select: u16::from_le_bytes([block[i + 6], block[i + 7]]),
         })
         .collect())
 }