The test count is identical with and without the disc; only the clock differs

An addition to AGENTS 3b, from nearly repeating the failure it describes.

Checking the count in 25d73b4, the suite came back 278 passing -- the same 278 as
always. But GC_DISC was not set for that run, so all 58 disc tests hit their
`require_disc!` early return and were counted as passed. The number was right and
the coverage behind it was not.

What distinguishes the two runs is the wall clock and nothing else:

    without GC_DISC   58 tests,  4.10s
    with GC_DISC      58 tests, 36.14s

Same test count, same "ok", same zero failures. A reader -- including me -- has no
way to tell those two lines apart. That is a sharper version of the 3b failure
than the filtered sum was, because no amount of reading the output carefully
distinguishes them. The duration does, and it is in the line already.

So 3b now says: if a run finishes suspiciously fast, the disc tests did not run.
And it keeps the standing instruction to set GC_DISC when touching disc-decoding
code, since 25d73b4 changed texture-adjacent code and the verification genuinely
needed the disc.

Re-verified properly: 278 passed across 23 + 19 + 58 + 156 + 22, disc present,
36.14s on the disc binary. Clippy clean.

AGENTS.md

@@ -133,6 +133,11 @@ Concretely:
 - If the reported count moves between runs, find out why before writing anything
   down. A drop means either an environment difference or a failure, and the two
   look identical from the summary line.
+- **The total is the same whether or not the disc is present.** A skipped disc
+  test returns early and still counts as passed, so `cargo test --workspace` reads
+  278 either way. The only signal is the wall clock: the disc binary takes ~36s
+  with `GC_DISC` set and ~4s without it. If a run finishes suspiciously fast, the
+  disc tests did not run.
 - Never quote a number you computed rather than read.
 
 This is the same defect as rules 3 and 3a, one level up: a quantity that should