docs(files): record the general.host trap + that a green monitor proves nothing

Propagate the bare-hostname fix (10b86ae) to the docs that still said "three
traps", and write down the meta-lesson it exposed.

The bug was invisible to every check we had: Filestash strips the scheme
before its own Host check, so `curl /` returned 200, the API answered, wrong
passwords were rejected, and the brand-new Uptime Kuma HTTP monitor stayed
green — while the SPA computed `http://https://files...` and no browser could
use the site. An HTTP monitor asserts "server returned 200", which is a much
weaker claim than "the app works".

- CLAUDE.md / README: four traps now, host-scheme first; add the post-change
  check (`/api/config` → origin must be the real https URL).
- 19-routes: login form only renders at ?action=redirect (a bare 303 is
  normal, not a bug); assert origin after config changes.
- 10-uptime-kuma: an HTTP monitor cannot see an SPA break — use a Keyword
  monitor if you want teeth, and don't read green as "users can log in".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

plan/10-uptime-kuma.md

@@ -51,5 +51,13 @@ monitor stays green. Run both to tell *server down* apart from *path broken*.
   (Settings → Status Pages) so guests can self-check before pinging you.
 - Optional companion HTTP monitors for the web stack:
   `https://auth.${BASE_DOMAIN}`, `https://distribution.${BASE_DOMAIN}`,
-  `https://${BASE_DOMAIN}` — a red `distribution.` here explains client
-  mod-mismatch join failures.
+  `https://${BASE_DOMAIN}`, `https://files.${BASE_DOMAIN}` — a red
+  `distribution.` here explains client mod-mismatch join failures.
+
+> **An HTTP monitor cannot see an SPA break.** It asserts "the server returned
+> 200", which is a much weaker claim than "the app works". `files.` (Filestash)
+> proved this on 2026-07-14: a bad `general.host` made every client-side redirect
+> resolve to `http://https://files…`, so the site was unusable in every browser
+> while `/` kept returning 200 and the monitor stayed **green**. If you want a
+> monitor with teeth on a JS app, use Kuma's **Keyword** type against a string
+> the *rendered* page must contain, and don't read green as "users can log in".

plan/19-routes.md

@@ -65,8 +65,16 @@ base `https://auth.${BASE_DOMAIN}/drasl/api/v2` (`site.draslApiUrl`):
 login** for every player (`FILES_AUTH=htpasswd`), writable. Full design:
 `plan/20-files.md`.
 
-- `/` — SPA. `GET /api/session/auth/?label=files` renders the login form;
-  `POST` the same URL with `user`/`password` authenticates.
+- `/` — SPA. The login form renders **only** at
+  `GET /api/session/auth/?action=redirect&label=files`. Without `action=redirect`
+  the request falls through to the credential check, fails with empty creds and
+  303s back to `?action=redirect` — so a bare `/api/session/auth/?label=files`
+  returning a 303 is **normal, not a bug**. `POST` with `user`/`password`
+  authenticates.
+- `GET /api/config` → `result.origin` must be `https://files.${BASE_DOMAIN}`.
+  It's built as `(force_ssl ? https:// : http://) + general.host`, so a scheme in
+  `general.host` yields `http://https://…` and silently breaks every browser
+  while the server keeps answering 200. Check this after any config change.
 - `/api/*` — JSON API. Requires the header `X-Requested-With: XmlHttpRequest`
   (the SPA sends it); without it Filestash's intrusion detection 403s the
   request. Relevant when curling it by hand.