replay: demand-priority prefetch push-back scans the whole resident cache

[echemythia]

When a demand fetch preempts queued prefetch work under Discipline::DemandPriority,
ReadyLru::push_back_prefetches scans every resident entry to push back the ones that have
not landed yet.

That is O(resident cache size) per preemption, so O(events × cache size) worst case.

The bound is tighter than it looks in practice: the scan runs only under DemandPriority,
and only when there is genuine queued backlog (any_free_before > start), and the cache is
capacity-capped, so it is bounded by the ladder cap rather than by trace length. This is an
offline analysis harness, not the capture path.

Suggested fix

Keep prefetch entries in a BTreeMap keyed by ready_at, split off the (cutoff, ..)
range, and re-key just that range. That makes the cost O(k log n) in the number of entries
actually pushed back, rather than O(n) in cache size.

Not urgent, and worth doing only with care: the correctness behaviour it would preserve
(a preempted prefetch cannot report ready before the modelled link could have delivered it)
is recent, and a subtle re-key bug would be a worse outcome than the current constant
factor.

Affected

crates/s3tap-replay/src/link.rs.