Serve modpack.zip via Caddy static file, not Gitea (50MB cap)

modpack-final.zip is 78MB, well over Gitea's upload limit. Served
directly from Caddy's existing static/ mount instead (path-routed
within the minecraft.mivanchenko.de block, alongside the BlueMap
failover) - no new container or mount needed. install.sh/install.ps1
MODPACK_URL updated accordingly; install scripts themselves stay on
Gitea since they're small text files. Verified full byte-exact
download end-to-end. Also drops the stale "moving to the venue"
comments now that the server is permanently on mivanchenko.de.

HOSTING.md

@@ -112,15 +112,24 @@ Watch the console for `DH-Request Module Ticker` / world-gen-queue log lines —
 
 Repeat for Nether/End build areas if you want those pregenerated too (useful since the roadmap sends people there for Nether's/End's Delight dishes) — DH generates per-dimension automatically as each is loaded; no separate per-dimension command needed, just make sure you (or a connected client) actually visit those dimensions once during the pregen session to trigger their world-gen queues.
 
-## 3. File distribution: Gitea, not a local file server
+## 3. File distribution: Gitea for scripts, Caddy static file for the modpack
 
-`install.sh`, `install.ps1`, and (once built) `modpack.zip` are committed straight to the `mc-lan-party` repo on Gitea (`git.mivanchenko.de`, already proxied by Caddy and public), served via its raw-file URLs. No separate file-server process on the venue/server box — one less moving part, and it's fine for now per your call; worth revisiting (e.g. Gitea releases/LFS, or an object store) if `modpack.zip` turns out large enough that Gitea's raw-file serving gets awkward.
+`install.sh` and `install.ps1` (small text files) are committed to the `mc-lan-party` repo on Gitea (`git.mivanchenko.de`, already proxied by Caddy and public), served via its raw-file URLs.
+
+`modpack.zip` is **not** — Gitea rejects uploads over 50MB (hit this directly: `modpack-final.zip` is 78MB), and that's not something worth fighting Gitea's config for. Instead it's served as a plain static file directly by the same Caddy instance already fronting `minecraft.mivanchenko.de`, using the `static/` folder Caddy already had mounted (`~/caddy/static/`, previously just `maintenance.html`) — no new container, no new mount, no restart of anything shared:
+
+```bash
+# on the server, after you've built/scp'd modpack-final.zip to ~/lan-minecraft/
+cp ~/lan-minecraft/modpack-final.zip ~/caddy/static/modpack.zip
+```
+
+The `minecraft.mivanchenko.de` Caddy block path-routes: `/modpack.zip` → static file, everything else → the BlueMap mod/standalone failover (see above). Updating the zip later is just overwriting that file in place — no Caddy reload needed, `file_server` reads it fresh each request.
 
 Give participants:
 - **Windows:** `irm https://git.mivanchenko.de/mivanchenko/mc-lan-party/raw/branch/main/install.ps1 | iex`
 - **Linux / macOS:** `curl -fsSL https://git.mivanchenko.de/mivanchenko/mc-lan-party/raw/branch/main/install.sh | bash`
 
-Each script asks for a nickname, derives a stable offline-mode UUID from it (so the same name = same player data across the whole 3-day party, even if they re-run the script), seeds that into a fresh `accounts.json`, downloads Fjord Launcher Unlocked + the modpack from Gitea, and launches straight into the instance already connected to `minecraft.mivanchenko.de`.
+Each script asks for a nickname, derives a stable offline-mode UUID from it (so the same name = same player data across the whole 3-day party, even if they re-run the script), seeds that into a fresh `accounts.json`, downloads Fjord Launcher Unlocked from GitHub and the modpack from `https://minecraft.mivanchenko.de/modpack.zip`, and launches straight into the instance already connected to the same server.
 
 Make sure your Minecraft server itself is running with `online-mode=false` in `server.properties` — offline accounts only work against offline-mode servers.