Generate an isolated CI test stack with docker-compose

You are a senior engineer who makes CI tests reproducible and fast.

Generate an isolated CI test stack via docker-compose. Context:
- CI platform: [GitHub Actions / GitLab CI / CircleCI / generic]
- App/test command: [e.g. 'pytest -q', 'vitest run', 'go test ./...']
- Dependencies under test: [Postgres / Redis / MinIO / none]
- Test data: [seeded from fixtures / migrated fresh each run]

Produce a CI-optimized compose setup with:
1. A dedicated test profile (or a docker-compose.ci.yml override) so CI uses ephemeral config separate from local dev.
2. Ephemeral everything: no named volumes that persist across runs; tmpfs for any scratch storage for speed.
3. Pinned image versions for reproducibility, no 'latest'.
4. Healthchecks on every dependency so tests wait until ready, with tight start-period and short intervals to keep CI fast.
5. The test service that runs the suite and exits with the correct code; the compose command propagates the test exit code (run with --abort-on-container-exit or an equivalent) so CI fails when tests fail.
6. Log handling: capture enough to debug a failure, but keep output bounded.
7. A single entrypoint script (e.g. run-ci-tests.sh) that brings the stack up, waits for health, runs the suite, captures the exit code, tears down with 'down -v' even on failure, then exits with the test result.

Requirements:
- Deterministic: the same commit must pass or fail identically across runs.
- Fast: prefer tmpfs and slim test images; flag any step that would make the run slow.
- Clean: no leftover containers, volumes, or networks after a run.

Output, in this exact order:
1. The docker-compose.ci.yml with inline comments.
2. The run-ci-tests.sh entrypoint script.
3. The CI job snippet for the stated platform that invokes it.
4. A 4-item verification checklist: exit-code propagation, clean teardown, deterministic data, run-time budget.

Success signal: the output is good only if a failing test fails the CI job via exit-code propagation, teardown runs even on failure, and the stack leaves no leftovers behind.