Answer sprite collision through libakgl's narrowphase

`spr_collisions()` computed axis-aligned overlaps itself, because at libakgl
0.7.0 there was nothing to delegate to: `akgl_collide_rectangles()` has a
documented corner-containment defect and the physics backend's `collide` slot
raised "Not implemented". 0.8.0 brought a real narrowphase, and this moves onto
it.

The mask is bit-identical and every test from the previous commit passes
**unmodified**, which was the gate this stage had to clear -- including the two
that were written to be hard to satisfy. Edge-to-edge is still not a collision,
so a tile-aligned program is unaffected. The cross-shaped overlap is still
reported, which is the one that could have regressed: it is the case
`akgl_collide_rectangles()` gets wrong and the reason the hand-written loop
existed, and `akgl_collision_test()`'s box path gets it right.

What it buys is the contact -- a normal, a penetration depth and a point --
which four comparisons cannot produce. Nothing consumes it yet; that is the next
commit. It is here now because the mask and the contact come out of the same
test, and computing them in two places would be two things to keep in step.

**The first attempt was ten times slower and the benchmark caught it.** Syncing
all eight proxies and running the narrowphase on all twenty-eight pairs measured
984 ns a scan against 96 ns for the loop it replaced -- 21% of a frame at 256
scans a frame -- to produce a mask that was bit-identical and a contact that was
thrown away. Two changes fixed it, and both are what a broad phase *is* rather
than workarounds for a slow library:

- **Reject on the bounding boxes first.** The four comparisons that were always
  here now decide which pairs are worth an exact answer. The narrowphase still
  decides the bit -- the box test only says "maybe", which will matter the moment
  a shape is not the whole frame.
- **Do not sync a proxy that has not moved.** The scan runs at the top of every
  interpreter step and a sprite moves at most once in that time, so almost every
  sync would rewrite a proxy with what it already holds. Compared against the
  last synced rectangle rather than flagged by the verbs, because a host game can
  move a BASIC sprite through the actor registry and a flag would miss that.

Measured after: 54.9 ns at eight sprites spread out, which is *faster* than the
96.3 ns it replaced -- boxes are now built eight times a scan instead of
fifty-six. The number that matters is the new benchmark row for the arrangement
`examples/breakout/sprites/breakout.bas` actually has, which is 211.8 ns, or
4.5% of a frame. That game reaches it 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 those pairs can never be rejected. Roughly double the old
cost, for contacts. Recorded in MAINTENANCE.md with the two synthetic extremes
either side of it as a bracket.

The eight proxies are claimed once at init and held, so exhaustion of the pool
shared with an embedding host is an initialization failure that names the pool
rather than a collision scan refusing halfway through somebody's game. The shape
is built before the proxy is spawned from it and the acquire sits adjacent to the
initialize, which are two traps libakgl hit itself and documents.

`tests/akgl_backends.c` now tears the sprite backend down between cases. It never
did, and got away with it while init claimed nothing; eight proxies apiece across
twenty cases is a hundred and sixty against a pool of a hundred and twenty-eight.
A host releases what it took, and so does the harness.

Both games run forty seconds headless with no error line. 111 with akgl, 110
without.

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

MAINTENANCE.md

@@ -411,24 +411,32 @@ that have not moved. Is that worth changing to a per-frame cadence?
 
 Measured at `RelWithDebInfo`, scale 10, best of 5:
 
-| Row | ns/op |
-|---|---|
-| `spr_collisions`, 0 sprites | 19.4 |
-| `spr_collisions`, 2 sprites | 26.1 |
-| `spr_collisions`, 4 sprites | 40.3 |
-| `spr_collisions`, 8 sprites, all overlapping | 96.3 |
-| one rendered frame, 8 sprites + full text grid | 1,174,081 |
+| 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 | — |
 
-**The answer is no.** 256 scans at 96.3 ns is 24.7 µs against a 1.17 ms frame — **2.1%**, and
-that is the pathological case: eight sprites all overlapping, in a program that never blocks and
-therefore burns all 256 steps. The cost a program with no sprites pays is 0.42% of a frame. The
-frame is dominated by the text layer repainting every row it owns, which `TODO.md` already
-records as the real rendering cost.
+**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.
 
 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 2% of a frame is not worth changing when a handler fires for every program that
-already works. Recorded here rather than argued again.
+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.
+
+**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.
 
 **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