feat(compose): cluster-by-default Caddy-fronted stack with bare-metal join

`docker compose up` from a clone builds one image and brings up the whole stack
— PostgreSQL, console, Caddy, channel, and 10 server nodes — sharing one
Postgres so the console discovers every node. The dashboard is reachable only
through Caddy (HTTP/2 avoids the browser's 6-connection cap on the dashboard's
SSE streams); the console's plain-HTTP port is no longer published. Postgres
binds 127.0.0.1 so a bare-metal turnstone-server can join the cluster — the
bare-metal overlay is folded in and removed. Insecure dev defaults keep it
zero-config; the bundled production stack mirrors the shape but pulls ghcr
images and requires real secrets.

Move the Caddyfile under turnstone/deploy so it ships in the wheel; update docs,
QUICKSTART, and .env.example to match.

QUICKSTART.md

@@ -42,13 +42,13 @@ That's it — no flags, no arguments. The wizard prompts for everything.
 
 ## Deployment Modes
 
-The wizard supports two deployment modes:
+- **Single-node production** — `docker compose up` against the bundled
+  `turnstone/deploy/compose.yaml`: 1 server + console + channel + PostgreSQL,
+  pulled from ghcr.io. Good for most deployments.
+- **Local multi-node cluster** — clone the repo and run `docker compose up` at
+  the root for a 10-node fleet + console + Caddy + channel, built locally.
 
-- **Single-node production** (`docker compose --profile production up`) —
-  1 server + console + PostgreSQL. Good for most use cases.
-- **Multi-node cluster** (`docker compose --profile cluster up`) —
-  10-node server fleet + console + PostgreSQL. For high-throughput or
-  HA deployments.
+See [docs/docker.md](docs/docker.md) for both.
 
 ## Example Session