docs(lens): flag the exposure misdirection and the 10-30 degree solver database

[brickbots]

Closes #613.

What is left of #613

Most of #613 already landed. BOM.rst got the sensor-aware rewrite of the lens
advice, troubleshooting.rst gained the "Did you fit a different lens?"
bullet under "It won't plate solve", and menu_map.rst documents the Lens
setting. This PR adds only the two gaps that remained.

1. The failure looks like an exposure problem. Under "It won't plate solve"
the Exposure bullet comes before the lens bullet, so a reader with a wrong
Lens setting works the exposure bullet first and finds nothing. The lens bullet
now names the misdirection:

This looks like an exposure problem. On AUTO the PiFinder keeps working
its way up and down the exposure range and still never solves. Check the Lens
setting before you spend more time on the exposure.

I left the bullet order alone. The lens bullet is last because the two trailing
.. note:: blocks belong to it, and moving it above Exposure would orphan
them or split the list. The warning inside the bullet addresses the diagnosis
problem directly, and leaving the order untouched keeps this diff clear of the
concurrent edit to the GPS section of the same file.

2. The tetra3 database range. The BOM note for the 16mm lens already
explained that field of view depends on the camera as well as the lens. It now
records the actual constraint on substituting one:

The bundled star-pattern database sets the real limit on what you can
substitute. It is built for fields between 10 and 30 degrees. A camera and
lens that together see less than 10 degrees, or more than 30, cannot plate
solve at all.

Where the 10-30 degree range was verified

Read directly out of the shipped database rather than taken from the ADR:

$ python -c "import numpy as np; pp = np.load('python/PiFinder/tetra3/tetra3/data/default_database.npz')['props_packed']; print(pp['min_fov'][()], pp['max_fov'][()])"
10.0 30.0

That is the file PiFinder/solver.py:873 loads
(tetra3.Tetra3(utils.tetra3_dir / "data" / "default_database.npz")), and those
are the same min_fov / max_fov keys that
solver.py::_warn_if_outside_solver_database reads back at
solver.py:171 to log a gate that lies outside the database. ADR 0029's
[10.0, 30.0] claim checks out.

One issue bullet is superseded

#613 says "No restart needed: the solver re-reads the lens per frame and
solving resumes on the next one." That is no longer true, and I have not
documented it. PiFinder/ui/callbacks.py::set_camera_lens now restarts
deliberately: tetra3's _pattern_cache is keyed on the pattern hash alone, and
the entries it holds were already pruned against whichever FOV gate was in force
when they were computed, so a lens change leaves stale entries in place and looks
like it did not take until the solver restarts. See that docstring and ADR 0029.
The docs already say "The PiFinder restarts when you change it" in both
troubleshooting.rst and menu_map.rst, which is correct, so both are left as
they are.

Verification

python -m sphinx -b html -n -q source /tmp/sphinx_613 prints nothing and exits
0. The BOM.rst list-table cell renders as a single <td>, checked in the
built HTML. No em-dashes or semicolons in the added lines.

🤖 Generated with Claude Code