Make the landing snow actually render on an idle screen

[TheGreatAxios]

CL-5737: Landing snow is never drawn

Fixes three independent gates that all had to be crossed before the snow decoration over the landing-screen mountain (src/tui-opentui/mark-anim.ts, rendered via src/tui-opentui/landing.ts) could ever draw:

1. createLandingAbove mounts with still=true, and the old snowOn check (!input.still && alpha === 1) tied snow visibility directly to that flag — so the mount-time paint had no snow, by construction.
2. paintLanding in shell.ts early-returned unless re-entered with animating: true, which never happens while idle.
3. Its only caller was the turn monitor in runtime-bridge.ts, which deliberately stops ticking once idle (ANIMATION_TICK_MS vs DEFAULT_TICK_MS, monitor === undefined disables scheduling) — so even fixing (1) and (2) would leave nothing driving repaint while idle.

The design question: what drives frames for an idle surface

Two candidates were on the table for (3): a mount-scoped timer, or riding the renderer's own FRAME event. The first version of this PR chose FRAME, reasoning it avoided a second clock source. That turned out to be wrong, and was reverted — see below.

Why the FRAME approach failed

This renderer is purely on-demand: it never calls start/auto/requestLive, and only renders when something is dirtied. paintLandingMark assigns a freshly allocated StyledText to every row on every call, and the content setter does reference-identity comparison, so a fresh allocation always looks "changed" and unconditionally requests another render. Because FRAME fires from inside the render loop, that request reschedules the very next frame — each paint call is what causes the next one to be scheduled. Riding that event for the idle repaint means the paint that produces frame N is what schedules frame N+1.

The first version of this PR throttled that repaint to ~125ms to cut what looked like an accidental ~60fps loop down to ~8fps. That throttle broke the loop outright: since the throttle interval is necessarily longer than the frame interval, the frame immediately following a throttled paint is always a "skip" — no dirty, no reschedule — and the on-demand renderer parks for good. Measured: the pre-throttle build self-drove 166 frames in 3 seconds with nothing external calling render; the throttled build self-drove exactly 1 frame in 3 seconds, then froze forever. This is not a tuning problem — any throttle above zero frames kills the loop, because the throttle and the frame source were literally the same mechanism.

The fix: a mount-scoped timer

Reverted the throttle and the FRAME hookup entirely. The landing exists for the lifetime of the shell until the first transcript row tears it down (clearLandingMark), so a plain ~125ms setInterval, armed right after the shell's internal state is set up in createAppShell and cleared on whichever teardown happens first — the landing going away, or the whole shell disposing — is a clock source independent of the render loop's own scheduling. It repaints only while idle (landingAnimating false), so it never fights paintPhaseAt in runtime-bridge.ts, which still drives the mountain's own draw/fill/fade timeline off the turn monitor's clock while a turn is processing.

The timer also self-cancels once renderer.isDestroyed is true. Headless test harnesses commonly destroy the renderer directly (withTestRenderer's cleanup) without calling shell.dispose(); without this check the timer would keep firing 125ms ticks against renderables the harness already tore down, throwing across unrelated tests running in the same process.

What changed

• mark-anim.ts: snowOn no longer depends on still — only on alpha === 1 && !reducedMotion. still still freezes the mountain's own draw/fill/fade timeline to its filled frame; a new, separate reducedMotion input on MarkInput is the actual motion-suppression hook for snow. Nothing wires a live reduced-motion setting in yet, but the parameter is threaded end-to-end (renderMark → markChunks → paintLandingMark → paintLanding) and defaults to false everywhere, so behavior is unchanged until something sets it.
• shell.ts: paintLanding no longer early-returns when idle — it always repaints while the landing is up, since idle is exactly when snow needs to keep moving. createAppShell arms a ~125ms setInterval at mount that repaints the landing while idle; it is cleared in clearLandingMark (landing torn down) and in shell.dispose (whole shell torn down), and self-cancels if the renderer is destroyed out from under it. The renderer's FRAME event is no longer involved in driving the landing at all.
• landing.ts: docblocks that said still suppressed snow (stale after the snowOn change) now describe the actual split: still = idle-mount/frozen-timeline state for the mountain, reducedMotion = the motion-suppression hook for snow. Unchanged from the previous revision.

Test

src/tui-opentui/landing.test.ts has a test that mounts the shell via createAppShell (the real production entry point) and asserts the mark actually moves over real wall-clock time with no manual frame pumping at all — no renderOnce() loop, no hand-set clock passed to paintLanding. This is deliberate: every other test in this file (and the first version of this test) drove the mark by calling paintLanding directly, or by pumping renderOnce() in a loop to manufacture frames. Both of those stay green even when the production driver is completely dead, which is exactly how the throttled build shipped with frozen snow while its own tests passed. The new test only reads the final state via h.flush() (waits on the renderer's own scheduler settling, not a forced render), so the only thing that can move the snow between the two captures is the shell's own mount-scoped timer.

Verified by hand against both prior commits on this branch: the new assertion fails on the throttled build and passes on the pre-throttle build, confirming it actually distinguishes a self-driving loop from a dead one.

Two existing tests directly encoded the old "still implies no snow" and "idle re-entry produces the exact same frame" behavior; both were updated deliberately rather than deleted, since that behavior was intentionally changed here.

Also verified live: ran the built binary in a 120x40 tmux pane, let it sit idle on the landing screen, and diffed two tmux capture-pane snapshots taken several seconds apart. The · snow glyphs moved rows/columns between captures while every mountain block glyph (▁▂▃▄▅▆▇█) stayed in the same position.

Validation

• bun run typecheck: pass
• bun run build: pass
• bun run test: 4226 pass, 0 fail (317 files)

This supersedes #380, which added the snow-drawing code but never made it reachable; that PR should stay open until this one is reviewed and can then be closed in favor of this one.