Multi-view: the startup loss burst pauses the last cell for good ("Paused: decoder overloaded") #148

Seen on Aceline-1 (AG-216), 3×3 grid + U, 2026-10-13: right after the grid starts, all cells show decoder losses for a second or two (lost_fps 1–4 in 6–7 cells at once — every decoder starting together). The planner takes that for overload even on key frames, pauses the lowest-priority cell (slot 8, .53) — and the pause is never lifted: the cell stays Paused: decoder overloaded until the grid is restarted, although the decoder has plenty of room afterwards (all cells on key frames, no losses for minutes).

Reproduced on v2 (ea5c093) in 1 of 2 cold starts, and with #146 in 3 of 3 (the startup timing differs, not the cause).

Fix ideas:

• no loss-based decisions in the first seconds after the grid starts (a warm-up; isSettled already waits 5 s per cell, but cells settle at different times and the burst is shared);
• a paused cell gets another try after a quiet period (like promotions after PROBE_QUIET_MS), so a pause is not for ever.