docs(release): bring the 2.6.2 notes up to the release..main delta

[brickbots]

The 2.6.2 release notes described main as of #619. Five commits have landed since the branch point with release, and the notes covered only the lens ones (#624, #625, #628). This adds the other two and corrects two figures that #628 left stale.

What was missing

#622 — nearby ranking (ADR 0030)

New ## Fixes section. The BallTree behind both the object list's Nearby sort and the chart's nearby-DSO marker layer was built and queried as [ra, dec] against sklearn's haversine metric, which reads dimension 0 as latitude. Separations were right only between objects on a shared meridian, and worse towards the poles.

Also covered: the NEAREST_LIST_CAP = 200 window and what it costs the user, the great-circle staleness trigger replacing per-axis degrees (and MAX_TIME 2 s → 10 s), the carousel counting _menu_items_sorted rather than the source, the cursor policy (top row follows the pointing, a scrolled cursor pins to its object), and the serialize_ui_state truthiness fix that had been silently blanking the remote web interface's object-details view for every object opened from a Nearby list.

#623 — observed-objects cache

One chunked, catalog-grouped query instead of a lookup per listing, and one shared ObservationsDatabase per UI process. Includes the measured numbers and why grouping by catalog code is load-bearing (SQLite will not drive a two-column index from a row-value list, so a single logged WDS listing dragged ~131k rows into every chunk).

Corrections to existing text

Two figures survived #628's 13.04 mm measurement:

• the worked example in "Lens Selection" still said a 12 mm on an imx296 images 17.8°. It derives 16.38° — the table three paragraphs below already said so. The argument is unaffected; 16.38° is still outside the old [8.0, 16.0].
• Known Sharp Edges still said the 12 mm's effective focal length was "the nominal 12.0 standing in for a measurement nobody has made, flagged in the data as effective_focal_length_measured=False". It is measured, and the flag is true. What remains open on Calibrate the 12mm lens on-sky: effective focal length, SQM zero point, f-number #612 is the SQM zero point and the f-number, which the bullet and the follow-up entry now say.

Also added

• Why fix(optics): measure the 12mm's effective focal length (13.04mm) #628 mattered to self-heal: at the nominal 12.0 a 12 mm unit fitted 7.9% from derived, outside the 5% identification tolerance, so identify_lens_from_fitted_fov returned None on every frame and affected units would have solved on the wide assumed gate forever without ever promoting. At 13.04 mm that error is −0.07%.
• The single-sample caveat on 13.04 mm, as a sharp edge.
• The failed-solve log line, which hardcoded FOV est: 12.0°, max err: 4.0° and had been describing a window the solver had not used since Derive field of view from the optical train (sensor × lens) #609.
• SortOrder.RA gaining an implementation — the enum, the marking-menu branch and the "Sorting by RA" message all existed, but sort() had no branch, so selecting it announced a sort and left the list alone. Recorded as a sharp edge that it is still not offered in the Quick Menu.
• ObjectsDatabase.get_object_ids_by_listings(), the get_nr_of_menu_items() override, and ADR 0030 (including why it was renumbered off 0029).

Verification

Every figure quoted was checked against the code in this worktree rather than carried over from the source PRs:

• the FOV table (imx296 16.38 / 13.71 / 8.26, imx462 12.44 / 10.40 / 6.26, hq 20.43 / 17.12 / 10.33) recomputed from optics.OpticalTrain
• the assumed-lens gates (imx296 15.25 ± 3.59, imx462 11.57 ± 2.73, hq [8.78, 11.88]) recomputed from optical_train_for_profile(profile, None)
• test counts collected per suite; 1,305 unit + smoke passing measured locally, replacing the stale 1,285
• the logconf_default.json root-logger ERROR claim read from the file

Docs only — no code changes.

🤖 Generated with Claude Code