palette: cap project-scope results at 60 (mitigation for sluggish arrowing)

Reported: arrowing through project-scope results is sluggish, and switching back
to this-binary scope is instantly fast again.

Everything I can measure here says the palette is fine, so this is a
hypothesis-driven mitigation, not a proven fix. Ruled out by measurement:
  * per-option render + highlight move: 0.80 ms (local) vs 0.82 ms (project) at
    200 options each — identical and fast
  * wrapping from the binary-name prefix: none, 1.00 lines/option in both
  * option count driving render cost: flat from 20 to 400 options
  * an app-level OptionHighlighted handler doing work: none exists
  * scroll animation: Textual's scroll_to_highlight already passes
    animate=False, immediate=True
The synthetic pilot harness has a ~62 ms floor per press (Textual awaits a full
refresh cycle), so end-to-end key timing there is meaningless.

What remains plausible is simply LIST LENGTH in a real terminal: project scope
saturates its cap because every binary contributes, while a local filter usually
returns a handful — which matches the symptom exactly. So project scope now caps
at 60 rather than 200 (and fetches 3x that from the index). 60 is plenty for a
search palette; typing narrows further.

0 files changed, 0 insertions, 0 deletions