Add liveness and readiness probes for app container

[Besthope-Official]

Use Case

Current deploy setup only gates startup on db and redis container health. The app container has no explicit liveness/readiness contract, so failures such as partial startup, degraded dependency connectivity, or stuck workers are not detectable by health probes.

Proposed Solution

1. Add two HTTP endpoints in app:
   • GET /livez: process-level liveness probe, returns healthy if app event loop is responsive.
   • GET /readyz: readiness probe, returns healthy only when app is ready to serve traffic.
2. Define readiness checks to include:
   • database connectivity check
   • redis connectivity check
3. Add app service healthcheck in docker/docker-compose.yml using GET /readyz.
4. Keep depends_on service health conditions for startup ordering, and use app readiness as serving gate.

Alternatives Considered

N/A

Implementation Notes

• Files affected: src/http/routers/core.py, src/main.py, docker/docker-compose.yml
• Suggested status behavior:
  • liveness: 200 when process is alive
  • readiness: 200 when dependencies are reachable, 503 otherwise
• Readiness checks should be lightweight and bounded with timeout.

[Besthope-Official]

Current deployment is pure Docker Compose. Docker healthcheck has only one mechanism — it does not distinguish between liveness and readiness like k8s does (restart on liveness failure, remove from traffic on readiness failure). Splitting into /livez and /readyz has no practical effect since the orchestration layer cannot act on the distinction.

Additionally, the entrypoint already uses wait-for logic to guarantee startup ordering, and depends_on + upstream container healthchecks already cover dependency readiness at startup.

Suggest deprioritizing this until there is a concrete k8s migration plan, at which point probe semantics will actually be consumed by the orchestrator.