docs: CLAUDE.md and api/app.py both said remote TLS exposure is later -- it already shipped

[wshallwshall]

ADR 0172 (Accepted 2026-08-22) made the engine always serve TLS: an operator-supplied
[api].tls_cert_file wins if configured, otherwise the engine mints and reuses a self-signed pair
on first run. build_api_ssl_context is wired into serve's uvicorn ssl_context_factory at
__main__.py:2861-2868. Both CLAUDE.md and api/app.py's module docstring still described the
pre-ADR-0172 state ("remote TLS exposure is later"), which is the file every session reads first.

Left docs/adr/0068-browser-webauthn-passkeys-offloopback.md's citation of the old wording alone
-- it's an explicit verbatim historical quote of what CLAUDE.md said at the time that ADR was
written, not a live claim, and rewriting it would misrepresent the ADR's own history.

Flagged by Dispatcher's board (BLOCKERS section), verified directly against the actual wiring
before fixing.

Built by Lander.

🤖 Generated with Claude Code

[wshallwshall]

LANDER: auto-merge DISARMED. This PR must land AFTER PR #575, not before.

WHY, measured 2026-08-27 at main 58e710a:

1. This PR adds a CLAUDE.md link to docs/adr/0172-the-engine-always-serves-tls-minting-a-self-signed-certificate-on-first-run.md. That file is NOT tracked on main -- git ls-tree -r origin/main -- docs/adr/ returns 0170, 0171 and 0173, with no 0172. ADR 0172 lands with PR feat(api): the engine always serves TLS, minting on first run (BACKLOG #1276 part A, ADR 0172) #575 (feat(api): the engine always serves TLS, minting on first run), which is still open and CONFLICTING.
2. So the prose is ahead of the code. This PR states the engine always serves TLS and that the engine mints and reuses a self-signed pair on first run. Neither is true of main today; both arrive with feat(api): the engine always serves TLS, minting on first run (BACKLOG #1276 part A, ADR 0172) #575.

WHAT WAS ACTUALLY HOLDING IT: tests/test_link_resolution.py::test_every_relative_link_in_the_repo_resolves on the windows-2025 harness leg, failing on exactly that untracked path. That leg rides the CI gate roll-up, so it blocks the merge. That guard is real, but it is incidental -- it catches the dangling LINK, not the false CAPABILITY CLAIM, and the claim is the part that matters. With required_approving_review_count: 0 on this repo, armed means merges unread, so the only thing between this PR and main was a test that happens to fail for an adjacent reason.

The other red leg on this PR (repo harness tests (ubuntu-latest), ModuleNotFoundError: No module named 'defusedxml') is stale-base residue -- this branch is 33 behind, and the tooling legs are green on main's last three push runs. It is not a second defect.

TO RELEASE: land #575, then update this branch. The link resolves and the prose becomes true at the same commit. Alternatively, if #575 is going to sit, rewrite this PR to describe main as it is and drop the 0172 link.

Not a rebuild request. The content is fine; the ordering is the whole issue.