[NO TICKET] Add db healthcheck to docker-compose file

[TylerAdamMartinez]

Why

This PR addresses the following problem/context:

• The FastAPI backend container frequently failed to start in GitHub Actions due to PostGIS taking longer to initialize than standard PostgreSQL.
• The application attempted to connect to the database before PostGIS finished booting, causing repeated connection failures (db:5432 - no response / Waiting for postgres.).
• The test workflow’s health check waited on FastAPI, not the underlying database, so even increasing timeouts did not fix the issue.

How

Implementation summary - the following was changed/added/removed:

• Added a proper healthcheck to the db service in docker-compose.yml to wait for PostGIS to become ready (pg_isready).
• Updated app service to use depends_on: condition: service_healthy so FastAPI starts only after the database is fully initialized.

Notes

Any special considerations, workarounds, or follow-up work to note?

• Use bullet points here

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.
see 19 files with indirect coverage changes

[jacob-a-brown]

The health check is present in entrypoint.sh. should it go there or here?

[jacob-a-brown]

The only reason I really made entrypoint.sh was to do this health check. It makes sense to me to have it in the docker compose files for ease of understanding. In that case, we may want to add a step to populate the database (alembic upgrade head) and start the application (uvicorn main:app --host 0.0.0.0 --port 8000 --reload)

[jirhiker]

I like having the health check in the docker-compose file. It seems pretty standard practice

[jacob-a-brown]

If it's in docker-compose should we remove entrypoint? to keep a clean and consistent implementation