platformer: stabilise sprite-0 HUD by splitting below the HUD row

The previous commit parked the sprite-0 hit anchor on top of
the visible HUD coin at NT col 2, row 1 — the hit therefore
fired at dot 19 of scanline 15 (the HUD's last scanline) and
jsnes's PPU model applied the scroll change to the rest of that
same scanline, smearing the bottom row of every HUD glyph as
`camera_x` drifted. The score "0"/"2" digit, the heart, and
the lives "3" each flickered a handful of different pixel
patterns per frame as the scroll shifted. An in-harness
check for unique HUD states across the 180-frame window saw
~20-40 distinct states.

Fix: move both anchors off the HUD row entirely.

- `TILE_SPRITE0_ANCHOR` still has its single opaque pixel at
  row 7, col 3, but now draws at OAM `(248, 8)` so the pixel
  lands at screen `(251, 16)` — the first scanline of the
  playfield.
- New `TILE_BG_ANCHOR` (tile 28) mirrors it with a single opaque
  pixel at row 0, col 3; the map pre-paints it at NT `(col 31,
  row 2)` via the new `a` legend entry. Its one opaque pixel
  lands at the same `(251, 16)`, so the PPU's sprite-0 hit
  fires there instead.
- An explicit `scroll(0, 0)` right before `sprite_0_split`
  defensively re-latches scroll to zero in case jsnes has
  carried stale `$2005` state over from the previous frame.

With the hit on scanline 16, `$2005` writes in HBLANK of
scanline 16 (or thereabouts) only affect scanline 17 onward;
rows 8-15 all render at scroll=0 and the HUD glyphs stay
pixel-stable. The unique-state count across the 180-frame
harness drops from ~40 to 4 — and those 4 correspond to the
legitimate score / lives transitions (initial title, post-
stomp-1, post-stomp-2, etc.), not per-frame jitter.

Column 31 and OAM x=248 both sit inside jsnes's right-edge
overscan so the anchor pixels are invisible in the committed
golden. Goldens + gif refreshed.

tests/emulator/goldens/platformer.audio.hash

@@ -1 +1 @@
-94d0f184 132084
+efacd7d5 132084