fix(mhires): pad absent percell slots with bg0 to stop out-of-palette (green) flicker on slow transports

[kfox]

Problem

On the mhires percell path with a small forced palette (e.g. force_palette_indices = [0, 4, 6, 14]), cells flicker with green squares — a color that isn't in the allowed set — and letterboxed video shows the all-bg0 edge cells flashing (reads as a "flashing border"). Pronounced on the TeensyROM serial backend.

Root cause

Each 4×8 cell picks its top-3 non-bg0 colors with argpartition. A cell with fewer than 3 distinct non-bg0 colors present — the norm under a small forced palette, where most cells are mostly bg0 with 0–2 accents — left the surplus slots holding arbitrary zero-count palette indices. For an all-bg0 cell, argpartition returns index 5 (green) (among others) straight into the screen/color-RAM nibbles.

In steady state those filler slots are never selected (a present pixel resolves to its own in-set color), so on a fast transport the garbage stays invisible. But push() ships screen ($0400) / color ($D800) / bitmap ($2000) as three non-atomic writes. On a slow, ack-gated transport the VIC can read a new bitmap byte against a still-stale screen/color byte mid-frame and briefly render the garbage filler — the green-square flicker and the flashing letterbox edges.

Fix

Replace any per-cell pick whose smoothed count is 0 (never present in that cell) with bg0. Screen/color RAM then only ever carries colors genuinely present in the cell — nothing outside the source's set can leak — and the absent slots become a deterministic bg0, so present colors stop churning slots frame-to-frame. bg0 in a filler slot is a harmless duplicate (the %00 code already reaches it; the per-pixel argmin breaks ties to the real bg0 at slot 0).

No change to rendered output on fast transports — the filler slots were never selected there.

Verification

Offline, driving the real compose path with an mhires + percell + force_palette [0,4,6,14] config over 200 frames:

	frames leaking an out-of-palette index into screen/color RAM	leaked indices
pre-fix	200/200	[1, 5, 15] (5 = green)
post-fix	0/200	—

Tests

• New PercellFillerSafetyTest: screen/color RAM never carries a color outside the cell's present set; an all-bg0 cell collapses to solid bg0.
• Rewrote the stale excludes_bg0_from_per_cell_picks test to the correct invariant: bg0 fills only unused slots and never displaces a genuinely-present color.

Also in this PR

• test(menu): wrap an expected REU-staged "panel not drawn" WARNING in assertLogs — it was printing on every full-suite run and burying real failures.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.57%. Comparing base (e3d3aea) to head (7943c76).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage   79.56%   79.57%           
=======================================
  Files          68       68           
  Lines       12858    12861    +3     
  Branches     1898     1898           
=======================================
+ Hits        10231    10234    +3     
  Misses       2188     2188           
  Partials      439      439           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.