feat(ops): answer whether a running deployment can do its work

[L4XB]

Closes #45.

The gap

preflight.sh proves a configuration is internally consistent before the
stack starts. Nothing answered the question afterwards: whether the database is
there and carries its tables, whether documents can be written, whether the
configured mail host accepts a session, and which optional features are off and
why. An operator learned each of those from a failed user action — most often a
verification mail that never arrived.

What it looks like

$ docker compose --env-file .env.selfhost exec api six-community doctor
  ok  database                  reachable with all 89 tables
  ok  storage                   writable
 off  mail                      no SMTP host configured; public registration and verification stay unavailable
 off  metadata                  no contact address; scholarly metadata calls stay unidentified
 off  web search                needs a provider key and the data-processing confirmation
 off  speech                    needs a provider key and the data-processing confirmation
 off  public spoken interviews  needs speech processing and the explicit release gate
 off  public registration       closed; create accounts with 'six-community auth create-owner'

Every configured feature answered.

Two rules it follows

Off is a decision, not a fault. An empty provider key means the operator did
not enable that feature; reporting it as a failure would train people to ignore
the output. Only a configured thing that does not work is a failure, and the
command exits non-zero exactly then.

No secret is printed. The mail check names the host and port an operator
wrote in their own configuration, never the credentials, and it sends no login
and no message — it opens a session and leaves. A test pins this with canary
values for SIX_SMTP_USERNAME, SIX_SMTP_PASSWORD and SIX_GEMINI_API_KEY and
asserts none of them reaches the output, while the feature they belong to is
still reported.

The database check compares the tables the running build expects against the
tables the database has, so a stack started without its migrations says so in
one line instead of failing at the first upload.

quickstart.sh runs it after the readiness gate, and make doctor is there for
later. A failing check never tears down a running stack.

Validation

Four new tests, 208 source files clean under mypy, ruff clean, the
deployment script tests pass, and the export audit passes with the manifest
refreshed through #76's new mode.

[L4XB]

I have read and agree to the SixSentences CLA v1.0.