Frustum search: bounded with a proper filter, not found

e7eec01 located R and the camera; the remaining operand is the frustum. Searched
with the same shape of filter that found the camera -- structural invariant first,
differential second.

First attempt discarded: scanning for a perspective-matrix signature returned
11,846 hits, which is noise and means the filter was worthless. Recorded because
the number looks like a result.

Second attempt, the right filter: unit-length 3-vectors at 16-byte alignment, the
invariant that identified the camera matrices. 9,514 found, 188 forming clusters of
four or more. The six-vector cluster at 0x189e20 is a frustum's exact shape -- six
planes, 96 bytes -- and it is not one. It reads as three orthonormal basis vectors
plus a zero affine row at 0x30 stride, with a translation at 0x189ea0 near the
camera: a table of positioned things.

So the frustum is not located, and I am not picking the six-vector cluster because
six is the number a frustum has. That is rule 4's failure with an exact number
attached to make it feel earned, which is what I have already committed twice in
this investigation.

What the search did establish: the structured regions near the camera are the nine
matrices at 0x18aa70, orientation records at 0x189e20, and larger clusters at
0x1793f0 and 0x18b260. The frustum is not among them as planes.

Which points at the next search, and it is a different one: guard_band's signature
is Frustum { near, far, tan }, not six planes. If the frustum is stored as
near/far/tan scalars, the search should be for a stable float pair with a
plausible ratio, not for normals at all.

294 passing, clippy clean.

docs/plan/level-assets.md

@@ -2902,3 +2902,52 @@ selected, and a table selected by an index fits. The nine-legal-orientations-on-
 spherical-planet reading remains **plausible and unproven**; what is proven is
 which entry is live. No reindexing was observed over the sweep, so if the index
 does move, it does not on camera rotation alone.
+
+### Frustum search: bounded, not found
+
+`e7eec01` located `R` and the camera. The remaining operand is the frustum --
+`near`, `far`, `tan`. Searched with the same shape of filter that found the
+camera: a structural invariant first, a differential second.
+
+**First attempt, discarded.** Scanning for a perspective-matrix signature (a
+nonzero `col3` in row 2 with zero elsewhere) returned **11,846 hits**. That is
+noise, and the filter was worthless. Recording it because the number looks like a
+result and is not.
+
+**Second attempt, the right filter.** Unit-length 3-vectors at 16-byte alignment --
+the same invariant that identified the camera's matrices. 9,514 of them, of which
+188 form clusters of four or more within 256 bytes:
+
+    0x1793f0 .. 0x1796d0    36 vectors, 736 bytes
+    0x189e20 .. 0x189e80     6 vectors,   96 bytes
+    0x18a550 .. 0x18a580     4 vectors,   48 bytes
+    0x18aa70 .. 0x18ac90    27 vectors,  544 bytes   <- the nine camera matrices
+    0x18b260 .. 0x18b640    49 vectors,  992 bytes
+
+**The six-vector cluster at `0x189e20` is a frustum's shape** -- six planes is the
+right count and 96 bytes is the right size -- and it is not one. It reads:
+
+    0x189e20  [-0.4106,  0.9118, 0.0001]  |x|=1.0000
+    0x189e30  [-0.9118, -0.4106, 0.0001]  |x|=1.0000
+    0x189e40  [ 0.0001, -0.0001, 1.0000]  |x|=1.0000
+    0x189e50  [ 0.0000,  0.0000, 0.0000 ]  w=1.000
+    ... repeats at 0x30 stride ...
+
+Three unit vectors and a zero affine row: an orthonormal basis with no
+translation, which is an orientation record, not a plane set. A translation sits
+at `0x189ea0` = (246.857, 193.205, 49.891) -- near the camera position, so this
+region is a table of positioned things.
+
+**So the frustum is still not located, and I am not going to pick the six-vector
+cluster because six is the number a frustum has.** That would be rule 4's failure
+with an exact number attached to make it feel earned, which is the specific thing
+this project keeps warning about and the thing I have already committed twice in
+this investigation.
+
+**What the search did establish:** the camera-adjacent structured regions in EE
+RAM are the nine matrices at `0x18aa70`, orientation records at `0x189e20`, and
+larger clusters at `0x1793f0` and `0x18b260`. The frustum, if it is stored as
+planes, is not among them. If it is stored as `near`/`far`/`tan` scalars -- which
+is what `guard_band`'s signature suggests, since it takes `Frustum { near, far, tan }`
+rather than six planes -- then the search should be for a stable float pair with a
+plausible ratio, not for normals at all. That is the next search, and it is cheap.