Inspector: surface new-event catch-up in ascending timelines

[kevinswiber]

Problem

After #511, a parked descending timeline preserves its DOM window and shows an N new ↑ catch-up pill. Ascending order also preserves the parked window, but intentionally does not probe or show an equivalent indicator. New matching events can therefore arrive below the loaded window without a visible affordance.

Proposed behavior

• While parked in an ascending timeline, count matching events newer than an order-aware frozen live-edge anchor.
• Show N new ↓ in the topbar when the count is nonzero.
• Clicking the pill performs a one-time catch-up to the newest tail, resets the count, and preserves the existing descending-only meaning of continuous follow.
• Keep the currently displayed timeline window and open detail stable until that explicit catch-up.

Acceptance criteria

• The ascending anchor represents the newest already-loaded event, so existing rows are not counted as new.
• The existing /api/history/new-count endpoint is reused and active filters are respected.
• Polling does not inject new rows into a parked timeline DOM.
• The pill renders only for an ascending timeline with a nonzero count and uses the downward arrow.
• Catch-up reaches the newest tail, clears or deliberately preserves selection according to one documented rule, and resets/re-freezes stream-position state without enabling descending follow semantics.
• Order changes and stale probe/catch-up responses cannot commit against newer reader intent.
• Tests cover the order-aware anchor, filtered count, visibility, click behavior, and async races.

Follow-up to #511.

[kevinswiber]

The follow contract is being corrected first in #517, with the cross-product interaction study tracked in #518. This ascending-order proposal should be revisited there so it does not preserve PR #511’s assumption that follow is synonymous with a descending pinned viewport.