feat(caddy): replace basic_auth with form-based login (1Password-friendly)

[smartwatermelon]

Problem

Caddy's external-access protection on tilsit.vip uses the basic_auth directive, which triggers the browser's native 401 pop-up. Password managers (1Password in particular) cannot auto-fill into that pop-up, so every remote session requires manually typing the credential.

Proposed solution

Rebuild the custom Caddy binary with the caddy-security plugin and switch the external block from basic_auth to a form-based authenticate / authorize flow. Session via JWT cookie. Single user, bcrypt in a local store, no MFA. The LAN-bypass matcher stays unchanged.

Implementation plan

Full scoping in docs/plans/2026-04-19-caddy-forms-auth.md — 8 tasks, ~5–6 hours wall-clock, with rollback steps.

Merged via #129.

Deliberately out of scope

• Multi-user (single user for now)
• MFA / TOTP
• OIDC / OAuth federation
• Password rotation UX

Each of these slots into caddy-security later without rearchitecting.

[smartwatermelon]

Known plan inaccuracies to resolve at execution time

The plan at docs/plans/2026-04-19-caddy-forms-auth.md is scoped, not executed. The following issues were surfaced by Sentry / local review but were deliberately not fixed in #129 because they require live verification against the running caddy-security plugin version — whoever picks this up should handle them before/during Task 5:

1. users.json id field must be a UUID, not the username

Plan location: Task 5 Step 3, caddy-users.json template line with "id": "__OPERATOR_USERNAME__".

Issue: caddy-security's local identity store (authcrunch) validates id as a UUID. After substitute_template runs, "id": "operator" is a plain string and the store may refuse to load. Symptom: portal returns "no users matched" on every login, or Caddy fails to start at all with a UUID-validation error in the log.

Fix at execution time:

uuidgen
# paste into caddy-users.json before committing the template

Remove __OPERATOR_USERNAME__ from the id position entirely — the username stays in the username field. id is an internal primary key, nothing outside caddy-security references it. Generate once, commit the literal UUID, leave it alone.

2. caddy-security DSL tokenization risk

The plan calls out enable identity store vs enable identity_store in the risks section. Also applies to the identity-store declaration (local identity store localauth). These may flip between releases. If caddy validate rejects the snippet, underscore-swap is the first thing to try.

3. Inline {$JWT_SIGNING_KEY} vs from env JWT_SIGNING_KEY

caddy-security supports both. {$...} substitutes at Caddyfile parse time (raw bytes go into the parsed config); from env reads at runtime. The plan chose {$...} for consistency with how CF_API_TOKEN is handled. If HS512 validation rejects the key at parse time, switch to from env JWT_SIGNING_KEY in both the portal block and the authorization policy.

---

None of these require re-opening #129. Check them off here (or in comments) when each is addressed during actual implementation.