Deploy: make the NAS GUI path work, and stop sourcing the env file

Synology Container Manager and QNAP Container Station build a project from a
folder and look for `docker-compose.yml` in it. Pointing either at `docker/`
finds the DEV service stack and starts the wrong thing, so production now has
a root-level entry point.

- docker-compose.yml at the repo root: `include`s the prod stack (relative
  paths resolve against the included file's directory, so the build context
  and backup.sh still resolve) and pins `name: webmail-prod`. A project name
  typed into the GUI overrides the file's, so the docs say to type the same
  one.
- webmail.sh init now drops a `.env` symlink to docker/.env.prod in the repo
  root: the GUI reads `.env` from the project folder, and a symlink keeps one
  file to edit instead of two copies that drift.
- Required-variable guards on DATA_ROOT / MASTER_KEY / POSTGRES_PASSWORD /
  APP_DOMAIN. A bare `docker compose up` with no env file used to interpolate
  DATA_ROOT to "" and bind-mount /postgres at the root of the filesystem; it
  now aborts with a message naming the variable.
- require_env no longer sources the env file. Sourcing executed it as shell:
  ENABLED_PLUGINS=calendar contacts labels filters ran `contacts` as a command
  and broke every subcommand, and anything else in the file that holds the
  master key would have been executed too. Replaced with a compose-compatible
  KEY=VALUE parser; the template quotes the value as well.
- doctor: no longer aborts on a not-yet-created DATA_ROOT (set -e + pipefail
  killed it inside a `df` assignment — on exactly the pre-install run where
  its NFS/SMB check is the one that matters), and probes the nearest existing
  ancestor so that check works before the directory exists.
- docs §2.5 rewritten with what the GUI can and cannot do: no compose
  profiles (so no Meilisearch), no health-gated update, no restore; plus the
  Task Scheduler route for generating MASTER_KEY without enabling SSH, and
  why init/migrate showing "Exited (0)" is correct.

Verified by running `docker compose up -d --wait` from the repo root with no
-f and no --env-file (what the GUI does): all services healthy, migrations
applied, app served, and deploy/webmail.sh manages the same project.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nux3LCu4zP9nih4BRhPyHw

docs/nas-install.md

@@ -106,14 +106,62 @@ is small or you'd rather not tie it up, build on your PC instead — see §6.3.
 Open `http://your-nas:8088/`, create your account, and add a mail account
 through the wizard.
 
-### 2.5 Synology Container Manager (UI instead of SSH)
+### 2.5 Synology Container Manager (GUI instead of SSH)
 
-If you prefer the GUI: *Container Manager → Project → Create*, path
-`/volume1/docker/webmail/src/docker`, and select `docker-compose.prod.yml`.
-Container Manager reads a file named exactly `.env` from that folder, so run
-`cp docker/.env.prod docker/.env` first (and re-copy it whenever you change
-settings). The SSH route is still the better one — `webmail.sh` gives you the
-backup, update, health-gate and rollback logic that the UI has no equivalent for.
+Yes, this runs from the GUI. *Container Manager → Project → Create*, point it at
+the **repo root** (`/volume1/docker/webmail/src`), and name the project
+`webmail-prod`.
+
+Point it at the repo root, **not** at `docker/`. Both folders contain a
+`docker-compose.yml`: the one in `docker/` is the throwaway *dev* service stack
+(Postgres/Redis/Meilisearch/GreenMail on dev ports) and starting it does not
+give you a webmail server. The root one is production.
+
+Name the project `webmail-prod` too — the name you type in the UI overrides the
+one in the compose file, and keeping them the same means `deploy/webmail.sh`
+and the GUI manage the same stack instead of two rival copies.
+
+**You still need a shell once**, to create `docker/.env.prod` with a generated
+`MASTER_KEY` — there is no way to generate a random key in the GUI. Either SSH
+in and run `./deploy/webmail.sh init`, or, if you would rather not enable SSH at
+all, use *Control Panel → Task Scheduler → Create → Scheduled Task → User-defined
+script*, run as `root`, with:
+
+```bash
+cd /volume1/docker/webmail/src && ./deploy/webmail.sh init
+```
+
+Run it once, then edit `docker/.env.prod` in DSM's Text Editor (`init` also puts
+a `.env` symlink in the repo root, which is what Container Manager reads — one
+file, one place to edit).
+
+**What you get in the GUI:** start/stop, live logs, per-container resource use,
+automatic restart after reboot, and the nightly database backups (the `backup`
+service is an ordinary container, so it runs regardless of how you started the
+stack).
+
+**What the GUI cannot do:**
+
+| | Why | Instead |
+|---|---|---|
+| Start Meilisearch | compose profiles aren't exposed in the UI | `./deploy/webmail.sh up` — or delete the `profiles:` line from `docker/docker-compose.prod.yml` |
+| Health-gated updates | it just pulls and restarts; no gate, no rollback | `./deploy/webmail.sh update` |
+| Backup before migrating | — | `./deploy/webmail.sh update` does it automatically |
+| Restore a dump | — | `./deploy/webmail.sh restore <file>` |
+| Pre-flight checks, reindex | — | `./deploy/webmail.sh doctor` / `reindex` |
+
+**Two things that look wrong but aren't:** `init` and `migrate` sit there as
+**Exited (0)** — they are one-shot jobs that did their work and stopped, and
+every other service waited for them. And the first start builds both images on
+the NAS, which is slow and wants ~2 GB of RAM; §6.3 shows how to build them on
+your PC instead.
+
+After editing `.env`, containers keep their old values until they are recreated
+— `./deploy/webmail.sh up` does that cleanly.
+
+The honest recommendation: install and update over SSH, and use the GUI for
+day-to-day watching, starting and stopping. The update path is where all the
+safety lives, and it is the one thing the GUI has no equivalent for.
 
 ### 2.6 Starting automatically after a reboot