Trim glitch active window to 18s to cut worst-case payload margin

Reports of some rendered segments coming out too large for the physical
Gen1 device, suspected (correctly) to be complex/busy album art pushing
the glitch segment's payload up. Confirmed with synthetic adversarial
testing: colored noise art (sharp per-pixel detail surviving the
downscale to decode resolution, not smoothed-away high-res noise) at
the full 22s window + strong zoom + random position measured 354KB --
uncomfortably close to the Gen1 460KB limit. Isolating glitch from
baseline on the same noisy art (216KB without glitch, 354KB with)
confirmed the glitch segment itself as the primary driver, exactly as
suspected: it builds many genuinely distinct frames (jitter shifts,
hue-tinted bands, scanline sweep) from the live art, and busy/high-
entropy art means those frames compress far worse than against typical
album art.

GLITCH_ACTIVE_SECONDS cut from the full STATIC_OVERLAY_END_SECONDS (22)
to a flat 18 -- re-tested against the same adversarial noise art: 333KB,
widening the safety margin from 106KB (23%) to 127KB (28%). Re-accepts
the tradeoff this was widened past once before (jitter/bands/scanlines
go static for the last few seconds of a very-long "ending" window)
deliberately this time, for the payload headroom.

Verified: normal live-art render still well under budget (345KB), 0
black-corner hits in isolation at worst-case settings -- the duration
change doesn't touch any of the margin-safety mechanics, just how many
cycles play out.

subwave_nowplaying.star

@@ -591,12 +591,25 @@ GLITCH_STATE_POOL = [
 # (which can be up to STATIC_OVERLAY_END_SECONDS = 22s) because the
 # hue-shifted RGB-split bands this used to also drive were expensive
 # enough to push a real render past the 460KB device limit if sized
-# against the full window (measured 481KB at the time). Those bands are
-# gone now -- this only drives the base-art jitter, built on
-# render.Sequence + _glitch_shift (Padding), which compresses far
-# better: a real worst-case render at the *full* 22s now measures ~54KB.
-# So this now covers the whole window instead of a short burst within it.
-GLITCH_ACTIVE_SECONDS = STATIC_OVERLAY_END_SECONDS
+# against the full window (measured 481KB at the time). Those bands were
+# dropped for a while (jitter alone, measured ~54KB worst-case at the
+# full 22s) and this was widened to match -- but the bands have since
+# come back (see GLITCH_STATE_POOL above), and worst-case payload tracks
+# the *album art's own complexity*, not just whether bands are on: a
+# busy/high-entropy cover compresses far worse than typical art, since
+# every jitter/band/hue-shift state built from it ends up genuinely
+# distinct rather than mostly redundant. Measured against synthetic
+# noise art at the full 22s + strong zoom + random position: 354KB,
+# uncomfortably close to the Gen1 460KB limit for art this adversarial.
+#
+# Capped at 18s (not the full 22) as a deliberate safety margin against
+# that -- shorter than the max show_static window, so jitter/bands (and
+# the scanline sweep, which shares this duration -- see
+# SCANLINE_SWEEP_DURATION below) go static for the last few seconds of
+# an "ending" window on a very long remaining-time case, the same
+# tradeoff this was widened past once already, just re-accepted on
+# purpose this time for the payload margin.
+GLITCH_ACTIVE_SECONDS = 18
 _GLITCH_CYCLE_TICKS = GLITCH_STATES_PER_CYCLE * GLITCH_HOLD_TICKS + GLITCH_PAUSE_TICKS
 _GLITCH_TICKS_PER_SECOND = 20  # 1000ms / 50ms-per-tick
 GLITCH_REPEATS = int(GLITCH_ACTIVE_SECONDS * _GLITCH_TICKS_PER_SECOND / _GLITCH_CYCLE_TICKS) + 1