Snapshot both servers: the VPS catalog moves to server/vps, the home server joins as server/home

The catalog in server/containers had drifted from the VPS. Eleven compose
files and twelve units no longer matched what runs, and two running
services, Gbrown_Agent and BillTracker, were missing. server/vps is now a
copy of the live files, and panama-server reads from it.

server/home holds the home server's services in the same shape. They still
run under Docker, so the podman units there are drafts for a later move, and
nothing installs from that tree. PostHog, Sentry and Plausible are checkouts
of upstream repositories. Only their local files are kept, next to an
UPSTREAM file naming the repository and the exact commit.

Every secret in both trees is a ${VAR} reference named in .env.example, or
CHANGE_ME in files that are not compose files. The live servers still hold
some of those values inline, so a live file can differ from its copy on
those lines alone. Existing .env.example files keep their comments, with new
keys appended at the end.

The ignore rules and the secrets contract now cover both trees, plus the
volume/ and volumes/ directories the home server uses.

server/README.md

@@ -6,13 +6,34 @@ screen, plus rootless podman compose services managed as systemd user units.
 
 ```
 server/
-  containers/     One directory per service: compose.yml, the
-                  podman-<name>.service user unit, and an .env.example
-                  naming what the service needs told
+  vps/            The catalog panama-server installs from, one directory
+                  per service: compose.yml, the podman-<name>.service user
+                  unit, and an .env.example naming what the service needs told
+  home/           The home server's services in the same shape (see below)
   scripts/        update-containers, the nightly image updater
   systemd/        The units behind it, linked by setup-server
 ```
 
+## The home server
+
+`server/home/` mirrors `~/Server` on the home server, where the services still
+run under Docker. Each directory has the same three files as the VPS catalog,
+and the unit is drafted for the eventual move to rootless podman. It has never
+run, and the composes still use Docker-only features (host networking, the
+GPU, the Docker socket) that need converting first. Nothing here is
+installable: panama-server reads `server/vps/` only, so a service moves into
+the catalog when it actually moves to podman.
+
+Paths keep their nesting (`server/home/Agents/Gitea` is `~/Server/Agents/Gitea`).
+Three services are checkouts of upstream repositories. For those, only the
+local files are kept, and an `UPSTREAM` file names the repository and the exact
+commit the checkout sits at: `PostHog`, `Sentry` and `Plausible`.
+
+Both trees are snapshots of the live machines with every secret replaced by a
+`${VAR}` named in `.env.example`, or by `CHANGE_ME` in files that are not
+compose files. The live servers still carry some secrets inline, so a live
+compose and its copy here can differ on those lines alone.
+
 ## The contract with ~/Server
 
 The repository carries the definitions; the machine carries the state.
@@ -35,7 +56,7 @@ is what `panama server enable` refuses to start on.
 ## Conventions
 
 - Service directories are TitleCase, matching `~/Server` as it has always
-  looked: `server/containers/Gitea` becomes `~/Server/Gitea`.
+  looked: `server/vps/Gitea` becomes `~/Server/Gitea`.
 - Bind mounts live under `./data/` in new services. Imported services keep
   the volume path they were running with until their cutover, because the
   repo copy must render identically to the live one — renames happen with
@@ -73,7 +94,7 @@ ones — and verify it came back up. One service at a time, quiet hours.
 
 ## Adding a service
 
-Add `server/containers/<Name>/` with the three files, modelled on any
+Add `server/vps/<Name>/` with the three files, modelled on any
 existing service. The unit is the standard oneshot `podman compose up -d`
 shape (`WorkingDirectory=%h/Server/<Name>`); the shape contract pins the
 details. Secrets go in `.env.example` as `KEY=CHANGE_ME` lines.