Multi-view: one transient loss drops the learnt capacity to the floor and every cell stays on key frames #189

Seen on Aceline-1 (AG-216, .144), v2.07–v2.09, 3×3 grid with 8 cameras and the U cell. All nine cells show about 1 fps on key frames for hours, while on 2026-10-14 the same box played 2–3 cells at full rate (capacity 464979, failed_load 0 in the README's JSON screenshot).

Timeline from logcat (box time, 2026-10-15)

/stats.json afterwards: decoder.capacity 244800 (= MIN_CAPACITY, one 1080p30), failed_load 239719, all 9 cells decode: key frames, total load about 59 000 blocks/s.

Why it doesn't recover (DecodePlanner)

1. The losses at 17:09 came at a load (239 719) below a load that had just been proven (312 338). They still set failedLoad to it, cut proven to 0.9 × load and drop the capacity to the floor. One transient (other apps, a stalled stream, a network burst) wipes what the device has proven.
2. Promotion goes strictly by priority and returns at the first candidate that does not fit. Slot 1 (1080p at ~20 fps, about 162 000 blocks/s) lands at about 212 000–220 000, right at the FAILED_MARGIN limit of 0.9 × 239 719 = 215 747, so it is blocked. Lighter cells behind it, such as slot 8 (720p at 2 fps, about 7 000), are never tried.
3. The hourly retry of a failed load (FAILED_RETRY_MS) counts from quietSinceMs, which any lossy sample resets. With nine key-frame cells, an occasional loss somewhere keeps resetting it, so the retry never comes.

Proposed fix

• Losses at a load below proven count as a transient: demote as now, but keep the capacity at least at proven and do not lower failedLoad below it.
• Time the failed-load retry from the last demotion, not from the last lossy sample.
• When the highest-priority candidate does not fit, still promote a lower-priority cell that fits (only within the capacity, no probing beyond it out of order).

Unit tests for each case. Then on .144: the same 3×3 grid should get back to 2–3 full-rate cells, and a 60-cycle grid ↔ single run (#76) should show no ANR.