fix(compose): pin auth./pack. to host-gateway so HTTPS resolves in-container

Containers don't inherit the host's /etc/hosts; the LAN resolver returns a
dead address (192.168.0.3:443) for the public names, crash-looping the
packwiz install on boot. extra_hosts host-gateway routes HTTPS through the
host's nginx (valid LE cert) -> caddy -> service.

Also add plan/10-uptime-kuma.md (Minecraft monitor: internal + public probes)
and document the HTTPS resolution variant in plan/00-overview.md.

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

plan/00-overview.md

@@ -52,6 +52,30 @@ Result: `http://auth.ulicraft.net/authlib-injector` and
 `http://pack.ulicraft.net/pack.toml` resolve identically inside the stack
 (minecraft → caddy) as the public names do outside it (client → nginx → caddy).
 
+#### HTTPS variant (`extra_hosts: host-gateway`)
+
+The caddy alias only serves **http** on `mcnet` (port 80). Once the stack moved
+to https URLs (drasl `BaseURL`, `PACKWIZ_URL`, the authlib-injector agent must
+match the client's https endpoint), the internal http alias is no longer enough —
+the container needs to reach a **TLS** terminator holding a valid cert.
+
+Caddy does not terminate TLS internally; the host's nginx does (on `0.0.0.0:443`).
+So pin the public names to the host in the service, not to caddy:
+
+```yaml
+minecraft:
+  extra_hosts:
+    - "auth.${BASE_DOMAIN}:host-gateway"
+    - "pack.${BASE_DOMAIN}:host-gateway"
+```
+
+`/etc/hosts` (extra_hosts) wins over the Docker resolver, so the container reaches
+the host's nginx (valid LE cert) → caddy → service. This is required because
+**containers do not inherit the host's `/etc/hosts`** — on cochi the host resolves
+`auth./pack.` to the public IP, but inside a container the LAN resolver returns a
+dead address (`192.168.0.3:443`, connection refused), which crash-loops the
+packwiz install on boot. `host-gateway` sidesteps DNS entirely.
+
 ## Build / run flow
 
 ```