Jump-to-number silently fails under the Nearby sort once the list is capped

[brickbots]

Once #622 lands, the Nearby sort ranks at most NEAREST_LIST_CAP = 200 objects
instead of the whole catalog. scroll_to_sequence — the jump-to-number search
bound to the number keys — searches _menu_items_sorted, so it can only reach
what is inside that window.

Typing an object number with Nearby active does nothing for almost everything in
the catalog: the cursor does not move, no message is shown, and the typed number
stays in the input box as if it were still being entered. There is no signal that
the object exists but is out of reach.

Measured

Same fixture (All Filtered, warm solve), counting distinct NGC sequences that
scroll_to_sequence can land on:

	reachable
before the cap (1cf39f22)	7 734 / 7 840 (98.6%)
after the cap (#622)	200 / 7 840 (2.6%)

(The 106 unreachable before the cap are listings deduplicate_objects merges
into a higher-precedence sibling — e.g. NGC 205 is present as M 110, so a search
for sequence 205 finds nothing. That is a separate, much smaller pre-existing
gap.)

Why this is worth separating from the cap's stated trade-off

#622 documents the cap's cost as "a Nearby-sorted list no longer scrolls down to
the object on the far side of the sky", and argues — correctly — that idly
scrolling to something 140° away has no observing use.

Jump-to-number is not that. It is a targeted action: the user already knows which
object they want and is asking to be taken there. Failing it silently is a
different and more annoying loss than truncating a scroll, and it is not covered
by the argument that justifies the cap.

Where it lives

python/PiFinder/ui/object_list.py

• key_number → scroll_to_sequence(self.jump_to_number.object_number)
• scroll_to_sequence iterates self._menu_items_sorted

Options

1. Search the source list, then switch sort. On a number match found in
   _menu_items but not in _menu_items_sorted, drop to SortOrder.CATALOG_SEQUENCE
   and land on it. Jump-to-number is inherently a catalog-order action, so the
   sort change is arguably the honest response to what was asked.
2. Search the source list, keep the sort. Land on the object without
   re-sorting — needs the cap to be lifted for that one object, or the row to be
   addressed outside the window, which the "two lengths" invariant in
   ADR 0029/0030 exists to prevent. Probably not worth the complexity.
3. Tell the user. Keep the current search, but show "Not in Nearby list"
   when the sequence exists in _menu_items and not in the window. Cheapest, and
   at least removes the silence.

Option 1 looks right: it does what the user asked, and the sort-order change is
visible on screen so nothing is silent.

Acceptance

• With Nearby active, typing a catalog number for an object outside the ranked
  window moves the cursor to that object (or explains why it cannot).
• Regression test alongside the fix(nearby): rank against true angular distance, in a bounded window #622 coverage in tests/test_ui_modules.py,
  asserting reach for an object known to be outside NEAREST_LIST_CAP.