Defer the JSON API until something consumes it

Supersedes decision 17, which expected endpoints to appear one at a time.
Nothing calls /api at all, so even that would be handlers with no callers and
golden tests guarding shapes nothing reads.

The contract stays in the spec as a design — it is what stops the shape
changing under a future client — marked as not built so the spec doesn't
claim behaviour the code lacks. later.md records what to build first when a
consumer appears.

docs/decisions.md

@@ -178,3 +178,10 @@ says so.
     preference. The limiter is keyed by email rather than IP (a proxy would mean trusting
     `X-Forwarded-For`) and locks the *attempt rate*, not the account, so nobody can lock someone
     else out by trying.
+43. **The JSON API is deferred entirely, not built on demand.** Decision 17 kept the contract fixed
+    and expected handlers to appear one at a time; in practice nothing consumes `/api` at all, so
+    even that trickle would be handlers with no callers, plus golden tests guarding shapes nothing
+    reads. The contract in [spec.md](./spec.md) stays as the design — it is what stops the shape
+    changing under a future client — and the first endpoint gets built the day something actually
+    calls it. Both surfaces being thin adapters over one data function is already true of the page
+    handlers, so adding the JSON side later stays a one-line-per-route job.