Replace Traefik with host-webserver reverse proxy in prod deployment

The production host runs cPanel, which already owns ports 80/443 for
other sites on the box -- there's no Traefik there. docker-compose.prod.yml
now binds the api container to 127.0.0.1:8000 only; the host's own
Apache/LiteSpeed (via cPanel) reverse-proxies api.amdbs.net to it and
terminates TLS itself (AutoSSL). Dropped the external traefik-public
network requirement and Traefik labels entirely.

Also corrected a separate latent inaccuracy while touching this: a bare
`docker compose up` (not `docker stack deploy`) never actually honored
deploy.replicas -- docs now say so and point at `--scale` instead of
implying free multi-replica scaling that was never really happening.

README's Production deployment section rewritten with concrete steps:
Cloudflare DNS record, cPanel subdomain + reverse proxy, then compose up.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

docs/api.md

@@ -198,8 +198,10 @@ of actually ingesting that movie or series, so there's no separate
 ## Administrative (section 17: "separately protected")
 
 Require header `X-API-Key: <one of AURORA_ADMIN_API_KEYS>`. Never exposed to
-public clients — mount behind a separate Traefik router/ACL in production if
-you want network-level isolation too.
+public clients — add a rule in the host webserver's vhost config for
+`api.amdbs.net` (e.g. an Apache `<Location>`/LiteSpeed rewrite blocking
+`/api/v1/admin/*` from outside a trusted IP range) in production if you
+want network-level isolation on top of the API key.
 
 | Method | Path | Body | Notes |
 |---|---|---|---|

docs/architecture.md

@@ -9,7 +9,7 @@ Aurora applications are consumers of it, never dependencies of it.
 ```
 Internet
     |
-Traefik
+Host webserver (cPanel-managed Apache/LiteSpeed — TLS termination + reverse proxy)
     |
 Aurora Core API replicas (stateless)
     |
@@ -191,8 +191,8 @@ development requires the observability stack to be running.
 `GET /health` — liveness only (process is up). `GET /ready` — checks
 PostgreSQL connectivity (always required) and Redis (required only if
 `REDIS_REQUIRED=true`, since Redis is disposable — see `docs/database.md`).
-Both are mounted twice: unprefixed (`/health`, `/ready`, for
-Docker/Traefik health checks) and under `/api/v1` (per section 17's endpoint
+Both are mounted twice: unprefixed (`/health`, `/ready`, for Docker/host
+webserver health checks) and under `/api/v1` (per section 17's endpoint
 list).
 
 ## Statelessness & horizontal scaling (section 1/2)
@@ -200,8 +200,10 @@ list).
 The API holds no in-process state across requests — no server-side
 sessions, no in-memory caches keyed by request. Every dependency
 (`get_db`, `get_redis`, `get_queue`) is request-scoped and backed by a
-shared pool. This is what makes `docker-compose.prod.yml`'s `api: replicas:
-3` behind Traefik correct without sticky sessions. Workers
-(`docker-compose.prod.yml`'s `worker: replicas: 2`) scale independently of
-the API — arq's Redis-backed queue ensures each job is claimed by exactly
-one worker.
+shared pool, so it's correct to run more than one API instance behind a
+reverse proxy without sticky sessions. Note that a bare `docker compose up`
+(as opposed to `docker stack deploy` under Swarm) does not itself honor a
+service's `deploy.replicas` — actually running multiple instances needs
+`docker compose -f docker-compose.prod.yml up -d --scale api=N`. Workers
+scale independently of the API the same way (`--scale worker=N`) — arq's
+Redis-backed queue ensures each job is claimed by exactly one worker.