docs: fold the monitor service into the stack-level docs

plan/23-monitor.md already covered the design; this makes the monitor
discoverable from the places someone actually starts reading.

- README: stack table, vhost list, DNS names, layout, and a setup section
  covering the bcrypt credential, the no-published-port model, and the
  --hard-on-first-deploy requirement.
- plan/00-overview.md: drop (PLANNED), add to the always-on service list, and
  note that it starts fine with Minecraft down (missing log and refused RCON
  are reported states, not fatal).
- plan/19-routes.md: vhost row, the four GET routes with their contracts, and
  the internal mcnet edges (mc-status for rosters so it needs no Drasl creds,
  RCON for TPS, Kuma probing healthz around caddy).
- caddy/Caddyfile: the snippet index had drifted — it listed five of nine
  vhosts. Added the four missing ones.

Two gotchas promoted to CLAUDE.md because they cost real time and will recur:

- Compose interpolates $-sequences in .env VALUES, so a bare bcrypt hash is
  silently corrupted before reaching the container, and the same bug bites
  again when writing one to a remote .env over ssh. Also records that caddy
  and filestash want opposite hash formats.
- The monitor container runs as root deliberately: /data is drwxr-x--- owned
  by uid 1000, so a USER directive would make the tailer silently read nothing
  while still returning 200.

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

plan/00-overview.md

@@ -152,10 +152,13 @@ mc-status, uptime-kuma and filestash.
 - `18-landing-rework.md` — join flow / rosters / account / mod list / footer (PLANNED)
 - `19-routes.md` — HTTP route reference (nmsr / landing / auth / files + internal)
 - `20-files.md` — Filestash player file share (`files.`, one shared login)
-- `23-monitor.md` — admin log stream + dashboard (`monitor.`, basic auth) (PLANNED)
+- `23-monitor.md` — admin log stream + dashboard (`monitor.`, basic auth)
 
 ## Boot/dependency order
 
 `caddy` (aliases) → `drasl` → `minecraft` (depends on drasl) → `mc-backup`.
-`nmsr`, `mc-status`, `uptime-kuma` and `filestash` are always-on and join `mcnet`
-(no ordering constraints — none of them are on the auth/boot path).
+`nmsr`, `mc-status`, `uptime-kuma`, `filestash` and `monitor` are always-on and
+join `mcnet` (no ordering constraints — none of them are on the auth/boot path).
+`monitor` reads Minecraft's log volume and queries its RCON, but starts fine
+without either: a missing log file and a refused RCON dial are ordinary states
+it reports rather than errors it dies on.