deploy/gen_env.sh: generate .env with openssl secrets

Builds deploy/.env from .env.example, generating SECRET_KEY and both
database passwords with openssl (base64/hex only, so nothing needs quoting
in the env file or the compose parser). Derives TS_HOSTNAME and
ALLOWED_HOSTS from the tailnet hostname, optionally sets
CORS_ALLOWED_ORIGINS/CSRF_TRUSTED_ORIGINS for split deployments, forces
DEBUG=False and writes the file with mode 600.

Modes: --no-prompt (defaults only), --update (refresh hostnames/auth key
while keeping the existing secrets, reading the stored FQDN from
ALLOWED_HOSTS), --force (rotate everything, with the SECRET_KEY warning in
the docs). Refuses to overwrite an existing file otherwise.

Verified: all modes, updated FQDN preservation, mode 600, and
docker compose config accepting the generated file.

deploy/README.md

@@ -37,6 +37,8 @@ docker compose -f compose.tailnet.yml up -d
 
 Notes:
 - Project names are `…-tailnet` so both sets can be installed side by side.
+- Serve needs no tailnet policy change (Funnel requires the `funnel` node
+  attribute in your ACLs), so this set works as soon as the sidecar joins.
 - Both sets use the same `deploy/data` directory (library, database, logs).
   Run one set per data directory — two MariaDB instances on one data dir would
   corrupt it. Giving the tailnet set its own `TS_HOSTNAME` (or running it on a
@@ -44,11 +46,30 @@ Notes:
 - Switching a host from funnel to tailnet (or back) is just starting the other
   compose file with the same `.env`.
 
+## Environment file
+
+`gen_env.sh` builds `deploy/.env` from `.env.example`, generating `SECRET_KEY`
+and both database passwords with `openssl`:
+
+```bash
+./gen_env.sh                # asks for the Tailscale auth key + hostname(s)
+./gen_env.sh --no-prompt    # secrets and defaults only; fill TS_AUTHKEY later
+./gen_env.sh --update       # refresh hostnames/authkey, keep the existing secrets
+./gen_env.sh --force        # regenerate everything, including SECRET_KEY
+```
+
+It derives `TS_HOSTNAME` and `ALLOWED_HOSTS` from the tailnet hostname you
+give it, and can set `CORS_ALLOWED_ORIGINS`/`CSRF_TRUSTED_ORIGINS` when you
+provide the frontend's hostname for a split deployment. `--update` is the safe
+way to add hostnames later; `--force` rotates SECRET_KEY, which invalidates
+signed media URLs and stored e621 API keys. The file is written with mode 600
+and is git-ignored.
+
 ## Usage
 
 ```bash
 cd deploy
-cp .env.example .env          # fill in TS_AUTHKEY, SECRET_KEY, ALLOWED_HOSTS, ...
+./gen_env.sh                  # or: cp .env.example .env and edit it yourself
 docker compose up -d          # default: everything on one host, public funnel
 # or
 docker compose -f compose.frontend.yml up -d