Collide sprites with rectangles that are not sprites

`SOLID id, x1, y1, x2, y2` registers static collision geometry; `SOLID id`
retires one and a bare `SOLID` retires them all, the way `TRAP`, `COLLISION` and
`DCLOSE` all read absence. `COLLISION 2` and `BUMP(2)` stop being refused and
mean *sprite met static geometry*.

**This is the thing eight sprite slots made impossible.** A wall of bricks wants
sixty, so until now a program could only collide with one by doing the
arithmetic itself against its own array -- which is exactly what both breakout
listings do, at about two hundred lines between them. A rectangle costs no sprite
slot.

The id is the **program's own number**, 1 to 64, not a minted handle. That is the
whole trick for "which brick did I hit": the id comes back out again, so a wall
built as `SOLID I#, ...` maps onto `B#(I#)` with no lookup, and retiring a broken
brick is `SOLID I#`.

`COLLISION 2` was refused with "sprite-to-background collision needs the screen
read back every frame", which was true of the question a C128 asks -- a sprite
against the bitmap's set pixels. `SOLID` gives this interpreter a background made
of rectangles instead, which is the same question in a form it can answer. Same
move `SPRSAV` made when it learned to take an image path.
`AKBASIC_INTERRUPT_BACKGROUND` has been sitting in the interrupt table commented
"COLLISION 2 -- sprite met background; refused" the whole time. Its accumulator is
separate, so a sprite hitting a wall never sets a bit in `BUMP(1)`.

**There is no `akgl_CollisionWorld` here, and that is deliberate.** libakgl's
uniform grid keeps its cell heads, cell size and origin in file-scope statics, so
it is one index per process -- and `akgl_collision_world_init()` ends in a
`reset()` that memsets those heads *and* calls
`akgl_heap_init_collision_cells()`. An interpreter embedded in a game with its
own collision world would have destroyed every registration that game had made,
on the first `SOLID` a script ran. So the geometry is indexed by an ordinary
array here and pairs go straight to `akgl_collision_test()`, which needs no
world. At sixty-four rectangles that is the right answer anyway; libakgl's own
numbers put a naive sweep at 0.7% of a frame at sixty-four objects.

**The scan now short-circuits when nothing has moved**, and that is what makes
any of it affordable. Its inputs are the sprites' boxes, which slots are
collidable, and the static geometry; if none changed the answer cannot have. A
frame runs one full scan and 255 cached ones. Eight sprites against sixty-four
rectangles is five hundred and twelve tests -- fine once a frame, ruinous 256
times.

The benchmark was rewritten to say which path it is timing, because with the
cache in place a loop that only calls the scan measures the short circuit and
nothing else. Breakout now costs 590.6 ns for its one full scan plus 255 cached
at 40.0, which is 10.8 us against a 1.19 ms frame -- **0.91%, less than the 2.0%
it cost before any of this work**, with static geometry and contacts added on
top.

`NEW` retires the rectangles, where it cannot undefine a sprite pattern: there
*is* an entry point for this one, so leaving them would be a choice, and the
wrong one -- a rectangle is invisible, so one left behind by a deleted program is
an unexplainable collision in the next. `CLR` leaves them alone.

`tests/sprite_verbs.c` gains the whole second path against the mock and its
`COLLISION 2` case is rewritten: it pinned the refusal, and now pins that type 2
arms its own handler without disturbing type 1's. `tests/akgl_backends.c` gains
the end-to-end version, including a full sixty-four-rectangle wall so the proxy
budget is exercised at its ceiling and the pool has to come back intact, and the
sixty-fifth refused by name.

A bare `SOLID` needed `akbasic_parse_optional_arglist` rather than
`akbasic_parse_arglist`, which `DCLOSE` already uses for the same shape.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwxGB6TdoVvZ11KQQME9cL

MAINTENANCE.md

@@ -411,33 +411,49 @@ that have not moved. Is that worth changing to a per-frame cadence?
 
 Measured at `RelWithDebInfo`, scale 10, best of 5:
 
-| Row | ns/op | as 256 scans of a 1.20 ms frame |
-|---|---|---|
-| `spr_collisions`, 0 sprites | 16.6 | 0.35% |
-| `spr_collisions`, 2 sprites, spread out | 29.6 | 0.63% |
-| `spr_collisions`, 4 sprites, spread out | 37.4 | 0.80% |
-| `spr_collisions`, 8 sprites, spread out | 54.9 | 1.2% |
-| **`spr_collisions`, breakout's own layout** | **211.8** | **4.5%** |
-| `spr_collisions`, 8 sprites, all overlapping | 800.4 | 17% |
-| one rendered frame, 8 sprites + full text grid | 1,203,923 | — |
+| Row | ns/op |
+|---|---|
+| full scan, 0 sprites | 59.2 |
+| full scan, 2 sprites, spread out | 153.3 |
+| full scan, 4 sprites, spread out | 229.0 |
+| full scan, 8 sprites, spread out | 366.4 |
+| **full scan, breakout's own layout** | **590.6** |
+| full scan, 8 sprites, all overlapping | 1145.4 |
+| **cached scan, nothing moved** | **40.0** |
+| one rendered frame, 8 sprites + full text grid | 1,191,947 |
 
-**The answer is no.** Even the row that matters most — the arrangement
-`examples/breakout/sprites/breakout.bas` actually has, which is the most demanding program
-here — is 4.5% of a frame, and it only reaches that because two of its eight sprites *are the
-screen*: a captured HUD strip and a captured play field, so the field's box covers everything
-and the bounding-box reject can never throw those pairs out. The frame is dominated by the text
-layer repainting every row it owns, which `TODO.md` already records as the real rendering cost.
+**Two paths, and which one a call takes is the whole story.** The scan short-circuits when no
+sprite has moved and no static geometry has changed since the last one — its inputs are exactly
+those, so if none changed the answer cannot have. A frame runs **one** full scan and 255 cached
+ones. The `full scan` rows nudge a sprite before each call to defeat that, so they measure a
+scan that actually ran; they therefore include a `MOVSPR`-equivalent, which is honest for
+comparison because a real frame pays that too.
 
-So the per-step cadence stays. It is what makes a collision report describe where the sprites
-have just been moved to rather than where they were (`src/runtime.c`, above the service call),
-and buying a few percent of a frame is not worth changing when a handler fires for every program
-that already works. Recorded here rather than argued again.
+So for `examples/breakout/sprites/breakout.bas`, the most demanding program here:
+
+    590.6 + (255 × 40.0) = 10.8 µs against a 1.19 ms frame — 0.91%
+
+**That is less than it cost before any of this work**, when it was 96.3 ns unconditionally on
+all 256 steps, or 24.7 µs, or 2.0% — and it now includes static geometry and produces contacts.
+The short circuit is what pays for both: eight sprites against sixty-four rectangles is five
+hundred and twelve tests, fine once a frame and ruinous 256 times.
+
+**So the per-step cadence stays**, and the question of moving it to per-frame is answered "no"
+twice over. It is what makes a collision report describe where the sprites have just been moved
+to rather than where they were (`src/runtime.c`, above the service call); it changes when a
+handler fires for every program that already works; and the cost it was supposed to save is now
+under one percent of a frame. Recorded here rather than argued again.
 
 **Read the two synthetic extremes as a bracket, not as an answer.** "Spread out" is every pair
 rejected on four comparisons; "all overlapping" is every pair going through to the narrowphase,
 which is a state no real program sits in. Real programs land between them, and the breakout row
 is there so the question "between them *where*" has an answer.
 
+Breakout reaches the high end of that bracket for a reason worth knowing: two of its eight
+sprites *are the screen*, a captured HUD strip and a captured play field, so the field's box
+covers everything and the bounding-box reject can never throw those pairs out. That is
+`TODO.md` §9 item 9, and fixing it would take this row down as a side effect.
+
 **Read a benchmark as a gap between two rows of the same run, not as an absolute.** libakgl's
 `PERFORMANCE.md` records a whole laptop reading 15% high on a later run, including rows nothing
 had touched.