Open the documentation page when an editor starts the service

[mjaksn]

Every launch configuration that starts the service now opens /docs in a
browser once the service is listening.

How

A new setting, open_docs, off by default. All seven configurations that start
the service set READERBOARD_OPEN_DOCS=1: four in .vscode/launch.json and
three in .idea/runConfigurations/. The two that start the sign simulator alone,
and the one that runs the tests, do not.

The waiting and the opening are the service's job rather than the editor's, and
that is the load-bearing part. It means the browser lands on the address actually
bound rather than one repeated in a launch file, which is what makes it right for
"readerboard against the real sign", whose port comes from a config file no launch
file knows anything about. Waiting for the port rather than sleeping a fixed time
is what makes it right on a slow start: the link to the sign is opened before the
socket is, and a browser opened too early shows a connection error for a page that
was going to work.

Nothing about it can take the service down. A browser that raises, a machine with
no browser, a port that never answers: each is a log line and nothing more. The
service drives a sign whether or not anybody is looking at a page.

The one change beyond the configurations

"readerboard against the loopback" in VSCode ran module: uvicorn, which does not
go through the service's entry point at all, so the setting could never have
reached it. Confirmed by running it that way with the variable set: no browser, no
log line. It now runs module: readerboard, which is what the PyCharm
configuration of the same name has always done, so the two read settings the same
way.

That would have cost it --reload, which is the point of that configuration, so
readerboard --reload now exists. Under it the open-docs wait stays in the
supervising process, so the tab opens once at the first bind rather than on every
restart.

Tests

tests/test_open_docs.py is new and is mostly about failure, because that is
where the risk is: a port that never answers, a browser that raises, a machine
with no browser at all. It uses real sockets rather than fakes, since what is
being tested is telling a port that answers from one that does not.

tests/test_launch_configurations.py covered PyCharm parsing; it now also loads
.vscode/launch.json and checks that every configuration in either editor which
starts the service asks for the documentation page, and that the ones which start
no service do not. That second half matters: without it the easy way to pass the
first is to put the variable everywhere, which would open a browser when running
the test suite. A configuration that quietly lost the setting would still run
perfectly and simply stop opening a tab, which is not something anybody reports.

Both new config tests were mutation checked: removing the variable from one
configuration fails the suite and names it.

Checks

708 tests pass, 18 of them new. ruff check . and mypy on the service and both
tools are clean, and docs/openapi.json is unchanged, so nothing here reaches the
API description.

Verified end to end with a stubbed browser on all three paths a configuration can
take: python -m readerboard, the same with --reload, and through
scripts/run_with_simulator.py. The launcher run used a non-default port and the
tab opened on that port rather than on 5001, which is the behaviour the whole
design is for.

Two judgement calls

open_docs is deliberately not in packaging/config.example.toml. It is a
development setting and that file is what gets installed on a Pi. It stays
discoverable: --print-config lists it, because that iterates the settings.

No version bump. [Unreleased] is back in CHANGELOG.md with the entry, which is
the shape the 0.3.0 cut left behind.