fix(street-level): Panoramax functional QA — nearest lookup, line cap order, hostile data

From an adversarial functional QA round against the live API:
- The nearest lookup missed pictures looking away from the click
  (place_position leaves them out at any tolerance): it now runs a
  bounding-box search beside it and ranks both by distance. A line
  clicked from high up searches its sequence within height / 100
  (50–400 m).
- The per-tile line cap kept the newest sequences, not the longest
  (lineCoverage re-sorted them): providers can now keep their decoded
  order (`keepOrder`).
- A long producer name froze the tab (quadratic email regex): linear
  check. A malformed link escape no longer fails the lookup; null or
  string coordinates no longer land at 0,0.
- A line with no camera type or day stays drawn under the filters.
- A sky click on a line changes nothing (as KartaView), instead of
  selecting a sequence with no cones.
- An unreadable tile reads as such; a failed neighbour z15 tile only
  thins the cones; unknown or refused ids say the picture is gone.
- Shared viewer: the sharp-panorama guard is per open (a late download
  of the previous photo no longer lets a second one start); an HD-only
  360° picture is shrunk or skipped like any original; panorama.js read
  the bitmap size after closing it, so 2:1 power-of-two panoramas
  clamped instead of wrapping.
- Tests for each, and for the gaps mutation testing found (preferred
  point, cone order, no reload within drawn tiles, newest-first gate,
  stale bitmap release, flat upgrade retry).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/CURRENT-STATE.md

@@ -3262,10 +3262,16 @@ density cells, binned to at most 96×96 points a tile (a z0 tile holds
 filters apply: lines carry their day and camera type, and a cell stays while
 it holds pictures of the kind asked for (cells are undated). A click on a
 line asks the core (`actions.openNearest`) for that sequence's picture
-nearest the click (`/api/search?place_position…&collections=<id>`, any
-direction: `place_fov_tolerance=180`), without framing, then any sequence's
-if it has none within 50 m; the filters go to the API (`filter=
-field_of_view=360`, `datetime=<since>/..`). Once the picture is on screen
+nearest the click, within the camera height / 100 (50–400 m: from high up
+a click lands well off a line), without framing, then any sequence's within
+50 m. Each lookup is two searches side by side, ranked by distance in the
+browser: `place_position` (nearest first, but even at
+`place_fov_tolerance=180` it leaves out pictures looking away from the
+point) and a bounding box (those too, but in no order); the filters go to
+both (`filter=field_of_view=360`, `datetime=<since>/..`). A line is dated
+by its sequence's first day, so a sequence still growing can hide under
+SINCE; a line with no camera type or day stays drawn. Lines keep the
+decoded longest-first order under the per-tile cap (`keepOrder`). Once the picture is on screen
 its sequence is highlighted and drawn as cones from the z15 tiles around it
 (their `pictures` layer, ~110 bytes a picture, against ~7.5 kB for a STAC
 item), plus a neighbour within 150 m of an edge; the cones re-centre when a