fix: the documented install path pulled :dev, not :latest (#3270)

docker-compose.yml pinned :dev on all five app services — web, worker,
scheduler, maintenance-long, ml-worker. The README documents
`docker compose -f docker-compose.yml up -d` as the production path, and
-f means "use only this file", skipping the override and its build:
directives. So Compose pulled image:, and image: was the rolling
development channel. The documented way to install this product shipped
development builds.

It went unnoticed for a structural reason rather than a careless one:
nobody who works on the project takes that path. The operator deploys
from a swarm stack file; contributors get docker-compose.override.yml,
which sets build: for all five services, and build: wins over image:. The
broken path is reachable only by a stranger following the README — which
is exactly the audience that did not exist until now.

:latest, per rule 147: main IS production. It is also what the agent
stack (agent/docker-compose.yml) already pinned, so this makes the two
stacks agree rather than introducing a new convention.

Both paths verified with `docker compose config`, which merges and prints
without starting anything:

  dev path        — build: present on all five, image: not pulled
  -f production   — 0 build: directives, five :latest images resolved

Also checked the base file for anything a stranger could not satisfy:
no host-absolute volume paths, no operator-specific port bindings, no
device mappings. The tag was the only defect in the consumer path.

The comment on web.image is deliberately long (rule 32). A line reading
:latest inside a file a developer is debugging with is exactly the line
someone flips back to :dev to test something and then commits, and the
consequence — strangers silently installing bleeding edge — is invisible
to everyone who works here.

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

README.md

@@ -69,9 +69,19 @@ or a `.env` file (see `.env.example` for the variable names) and use:
 
 ```bash
 docker compose -f docker-compose.yml up -d
-# (skips the override so containers pull registry images)
+# (skips the dev override, so containers pull published :latest images)
 ```
 
+`-f` is doing real work there: it tells Compose to use *only* that file, which
+skips `docker-compose.override.yml` and its local builds. What you get is the
+`:latest` images — the stable channel, built from `main`. This is the install
+path, and it is the one to use if you are running FabledCurator rather than
+working on it.
+
+`:dev` is the other channel: rebuilt from the `dev` branch several times a day,
+bleeding edge, no stability promise. Nothing in this repo points an installer at
+it, and nothing should.
+
 The GPU agent is deployed separately, on the machine with the card —
 `agent/docker-compose.yml`, not this stack.