0x152c70 rejected as the camera; the savestates are not consecutive frames

Ran the cheapest confirmation from a991088 on the candidate:

    [247.000, 194.000,  49.890]  step   0.000
    [293.960, 411.810, 115.000]  step 232.133
    [506.306, 311.614, 116.656]  step 234.804
    [300.170, 227.480, 128.000]  step 222.933

Rejected. A camera between consecutive frames moves a little; this moves ~230 units
per step and is not monotone on any axis. It is per-frame state but not a camera
position. a991088 wrote the prediction down before the measurement, so the
candidate is out rather than reinterpreted.

The more useful consequence: these four savestates are not consecutive frames, so
smoothness cannot filter the 2,005 candidates until consecutive frames exist.

Both cheap confirmations need something the savestates do not provide -- consecutive
frames, or an actual camera perturbation. That moves the camera hunt from offline
to needing a PCSX2 PINE session, the same category as the tfrag morph.

Worth noting the shape of it: the differential produced 2,005 candidates and the
confirmation reduced them to zero in one step, because the confirmation was
written before the measurement was interpreted rather than after.

286 passing with the disc and savestate present, clippy clean.

docs/plan/level-assets.md

@@ -2696,3 +2696,39 @@ plausible shape.
 Point 3 is the decisive one and it is cheap -- it is the same technique the
 lighting verification used. Points 1 and 2 need no emulator at all and run off the
 savestates already on disk.
+
+### Confirmation step 1 rejects 0x152c70, and the savestates are not consecutive
+
+Ran the cheapest of the three checks on the `a991088` candidate:
+
+    S 0x152c70 across 4 frames:
+      [247.000, 194.000,  49.890]   step   0.000
+      [293.960, 411.810, 115.000]   step 232.133
+      [506.306, 311.614, 116.656]   step 234.804
+      [300.170, 227.480, 128.000]   step 222.933
+
+**Rejected.** A camera between consecutive frames moves a little; this moves ~230
+units per step, and the series is not monotone in any axis. `0x152c70` is
+per-frame state, but it is not a camera position.
+
+That is the check working. `a991088` recorded the prediction in advance -- "a
+camera between consecutive frames moves a little, not 50 units" -- and the
+measurement says otherwise, so the candidate is out rather than reinterpreted.
+
+**The more useful consequence: these savestates are not consecutive frames.** They
+are four separate captures from different points, so "moves smoothly between
+frames" cannot be used to filter the 2,005 candidates at all until consecutive
+frames exist. That is a gap in the method, not a gap in the data.
+
+**What this changes about the plan.** The three confirmations from `a991088` were
+ordered by cheapness, and the two cheapest both need something the savestates do
+not provide: consecutive frames for smoothness, and an actual camera perturbation
+for the third. Both require a PCSX2 PINE session -- capture four consecutive
+frames, then move the camera and re-capture. The `docs/plan/pcsx2-verification.md`
+setup exists for exactly this, and the tfrag-lighting verification used it.
+
+So the camera hunt moves from "offline, savestates on disk" to "needs a session",
+which is the same category as the tfrag morph. Worth knowing now rather than after
+several more offline probes: **the differential measurement narrowed 2,005
+candidates to nothing, and it did that in one step, because the confirmation test
+was written before the measurement was interpreted.**