#4181 A limited model.output.search copies and sorts the whole listing on the event loop for each request, so that step still scales with the window

Problem

swamp-club#4143 made a limited model.output.search read newest first and stop at its limit, so reads scale with the limit. Before any read, though, YamlOutputRepository.findGlobalNewestFirst copies every in-window listing entry and sorts the copies by name stamp, synchronously on the event loop. The listing itself is shared between concurrent requests (listingScans), but the copy and the sort run once per request, so that work still scales with the window, multiplied by concurrent searches.

Evidence

This comes from code review of #4143 (PR #3496), not from a trace. The adversarial review estimated about a second per request at around 1M outputs for a limit 1 search with no since, but that figure is unmeasured. No ops trace shows this cost yet, and the phase spans do not time this step separately: it falls inside candidate_scan.

Proposal

First confirm it matters: time the ordering step, or check candidate_scan local time and event-loop lag on ops for limited searches. If it does, share the sorted order alongside the shared listing, since the order depends only on the listing, and apply each caller's window on top. Selecting the top entries with a heap, or sorting indices rather than copying entries, are alternatives.

Acceptance

Concurrent limited searches over one listing do not each pay a full copy and sort, and results keep the same order as the full scan, including same-millisecond ties broken by walk order. The property test in integration/model_output_search_limit_property_test.ts still passes.