feat: detect the django and postgres services

ahab guessed that the django service is called django and the postgres one db,
falling back on AHAB_DJANGO_CONTAINER and AHAB_POSTGRES_CONTAINER. The standard
project layout happens to agree, but nothing enforces it, and a stack naming
them web and database could not use ahab without setting both variables.

One `docker compose config --format json` call, roughly 120ms, resolves the
stack even while it is down, and the services are identified from what they
are rather than what they are called:

- postgres is the service whose image is a postgres flavour, matching postg,
  timescale, pgvector or citus. Nothing else counts.
- django is the service that both builds an image and has
  DJANGO_SETTINGS_MODULE in its environment. A celery worker sharing the same
  build and env_file matches too, so published ports break the tie: the service
  answering requests wins.

Neither guess is allowed to be wrong quietly. No match, or two candidates that
cannot be told apart, is an error naming the services it looked at. There is no
variable to fall back on: both container variables are gone, along with the
guessed defaults they backed up, so an ambiguous stack is fixed in the compose
file rather than worked around per developer.

Every service lookup goes through these rules, so `compose exec` and the whole
django group agree on which container they mean.

POSTGRES_USER and POSTGRES_DB come off the detected service, so dropdb,
createdb, pg_restore and pg_dump stop assuming the role and database are both
literally `db`, falling back to that only when the service declares neither.

Note that env_file entries are merged into a service's environment, so
POSTGRES_* is not safe for identifying the database service: one such line in a
project's .env would make the django service match as well. That is why
identification uses the image and only credentials use the environment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -62,6 +62,24 @@ ahab compose bash                   # shell in the django service
 ahab compose exec <cmd>
 ```
 
+## service detection
+
+`ahab` finds the services it needs in `docker compose config`, so they can be
+named anything:
+
+- **postgres**: the service whose image is a postgres flavour, matching
+  `postg`, `timescale`, `pgvector` or `citus`
+- **django**: the service that both builds an image and sets
+  `DJANGO_SETTINGS_MODULE`. A worker sharing the same build and `env_file`
+  matches too, so the one publishing ports wins
+
+If nothing matches, or two candidates cannot be told apart, `ahab` says so and
+lists the services it looked at rather than guessing.
+
+`POSTGRES_USER` and `POSTGRES_DB` are read off the detected postgres service, so
+`dropdb`, `createdb`, `pg_restore` and `pg_dump` use the role and database the
+project declares, falling back to `db` when it declares neither.
+
 ## django
 
 ```bash
@@ -100,6 +118,4 @@ from the git `origin` remote.
 
 Currently `ahab` respects the following environment variables.
 
-- `AHAB_DJANGO_CONTAINER`: control which compose service is used for sending django commands - defaults to `django`
-- `AHAB_POSTGRES_CONTAINER`: control which compose service is used for sending postgres commands - defaults to `db`
 - `AHAB_LINK_ROOT`: root of the out-of-repo store `ahab link` moves paths into - defaults to `${XDG_DATA_HOME:-$HOME/.local/share}/ahab`