After the PokeDB.org data import (beans-bs05) is complete, evaluate whether the seed data has grown enough to justify splitting seeding into a separate init container.
## Context
- Backend container is currently 76 MB; seed JSON data is ~5 MB
- After PokeDB import, seed data may grow significantly (filling in Gen 8+, Let's Go, etc.)
- The seed runner is tightly coupled to backend models/DB — a fully separate container isn't practical
- The pragmatic pattern: same backend image, different entrypoint as a one-shot init service in Docker Compose
## Approach (if we proceed)
- Add a `seed` service to `docker-compose.prod.yml` using the same API image
- Move `alembic upgrade head` + `python -m app.seeds` into the seed service command
- Use `restart: "no"` and `service_completed_successfully` dependency
- API service depends on seed completing before starting
- API command becomes just `uvicorn ...` — no migrations or seeding
## Decision criteria
- Measure the final seed data size after PokeDB import
- If seed data exceeds ~15-20% of image size, the split is worthwhile
- Even below that threshold, the separation of concerns (migrations/seeds vs serving) may justify it
## Additional benefits
- Failure isolation: seed failure prevents API startup cleanly
- Idempotency: seed runs once per deploy, API can restart freely
