style: order environment variables by how much the service needs them

environment: blocks were in no particular order. They now run must-have ->
should-have -> optional, with related variables kept adjacent as a group that
takes the tier of its most important member: PUID/PGID, PASSWORD with
SUDO_PASSWORD, DOCKER_MODS ahead of the INSTALL_PACKAGES and
NODEJS_MOD_VERSION that configure it, the four GIT_* entries, the PASEO_*
daemon settings.

Each .env.example is reordered to match its compose file. The names do not map
one to one -- PASSWORD feeds both PASSWORD and SUDO_PASSWORD, SERVICE_HOSTNAME
feeds HOST -- so an entry sits where the first compose entry reading it sits.

The HOST comment in both compose files is dropped; the READMEs already carry
that explanation in full. CLAUDE.md records the ordering convention.

alloy and gitea-mirror-local are untouched: every variable there is required,
so the tiers collapse and the existing grouping is the better one.

CLAUDE.md

@@ -41,6 +41,36 @@ links out to each service. Per-service detail (variables, ports, storage)
 belongs in that service's README, not the root one. Adding a service means
 adding its README and a row to the root table.
 
+## Environment variable order
+
+`environment:` entries are ordered by how badly the service needs them — not
+alphabetically, and not by when they were added:
+
+1. **Must have** — without it the service does not do its job, or is exposed.
+   Auth secrets, the uid/gid its files belong to, host allow-lists, proxy
+   trust, and the mod list that supplies the toolchain.
+2. **Should have** — it starts without these, but behaves wrongly for this
+   setup: timezone, default workspace, shell, git identity, pinned tool
+   versions, extra packages.
+3. **Optional** — cosmetics and conveniences; dropping one changes nothing
+   functional. Window titles, prompt labels.
+
+Grouping wins over the tiers. Variables that belong together stay on adjacent
+lines — `PUID`/`PGID`, `PASSWORD`/`SUDO_PASSWORD`, the four `GIT_*` entries,
+the `PASEO_*` daemon settings, `DOCKER_MODS` with the `INSTALL_PACKAGES` and
+`NODEJS_MOD_VERSION` that configure it — and the whole group sits at the tier
+of its most important member, even when a member on its own would rank lower.
+Within a group, the variable others configure comes first.
+
+Do not write the tier into the file as a comment — the order is the
+documentation. Where every variable is required, as in `alloy`, the tiers
+collapse and the existing grouping stands.
+
+`.env.example` follows its compose file's order. The names differ — one
+`PASSWORD` can feed several container variables, and `SERVICE_HOSTNAME` feeds
+`HOST` — so each entry sits where the first compose entry that reads it sits.
+Reordering a compose file means reordering the `.env.example` with it.
+
 ## Deployment target
 
 Services are deployed through Coolify and Dokploy, not plain `docker compose`