perf: a fleet at rest still repainted twelve times a second

[navbytes]

#146 stopped roost painting a frame it did not need, and set the budget
for the frames it does need at one C5 spinner frame — 80ms, because the
spinner is the finest thing on screen that moves with no event behind
it. That budget then applied whether or not any spinner was actually on
screen, and a fleet at rest is what roost spends most of its life being:
every pane idle or waiting, nobody at the keyboard, nothing moving at
all. Twelve frames a second of it.

So the budget is now two-tier. App::animating asks the one question
that separates them — is any pane's displayed status Working,
which is the single reason roost draws a spinner — and 500ms is spent
instead when the answer is no. Everything else time-driven is coarse (a
flash expiring, F1's hint window closing, a badge age tag ticking over a
minute), so half a second late is not a difference anyone can see.

idle, N shell panes, 200x50, release, no input
                    CPU     host bytes
before #144        2.75%       888 B/s
after  #144        1.70%       896 B/s
after  #146        0.60%       302 B/s
this change        0.20%        60 B/s

13x off roost's idle cost end to end, and 15x off its idle terminal
traffic. Flat in the pane count at every step — it was always fixed
per-frame chrome.

animating is not allowed to be load-bearing. CALM_REPAINT fires
unconditionally and does not consult it, so the property #146 was built
on is unchanged: there is no state in which the screen stops updating,
including one nobody thought to mark dirty or to teach animating
about. Getting it wrong costs a spinner stepping twice a second — a
stutter, never a freeze. It reads display_status (what the chrome that
draws the spinner reads) over runtimes (workspace-wide, because the
tab strip's summary and C27's roster spin for panes that are not on
screen), and it is a closure at the call site so the fleet walk happens
at most once per 80ms and never on an iteration that was going to paint
anyway.

Under load nothing changes: a pane producing output marks the loop dirty
and paints on the spot. tests/firehose.rs measures echo latency
p50=19ms max=57ms against its 250ms bound.

Gated by animating_is_true_exactly_while_the_fleet_has_a_spinner_on_ screen (including a pane working in a tab that is not on screen, and an
exited pane not counting) and by the extended
the_repaint_budget_always_fires_and_never_outruns_the_spinner, which
pins the ceiling firing on its own, the fine budget being the finer one,
and the fleet walk being asked only where its answer matters.