[Feat] Production-grade Liveness and Readiness Probes

Problem Description The current /is-up (liveness) and readiness endpoints blindly return 200 OK. In a production Kubernetes or Docker Swarm environment, the orchestrator relies on these to route traffic. If a pod loses its connection to Redis or Postgres but still returns 200, it will receive traffic and drop every request, causing severe outages.

Proposed Feature Implement production-grade liveness and readiness probes that actively ping critical infrastructure dependencies (Postgres and Redis) before declaring the node "ready" to serve traffic. Return 503 Service Unavailable if any dependency is unhealthy.

Alternatives Considered Continuing to return 200 OK requires users to rely on external monitoring tools to detect broken pods, which adds significant operational overhead.

Implementation Suggestions

• In v0/readiness.ts, check redisRateLimitClient.ping(), getRedisConnection().ping(), db.execute(sql\SELECT 1`), and dbRr.execute(sql`SELECT 1`)`.
• In v0/liveness.ts, ensure redisRateLimitClient.status isn't 'end'.

Use Case This ensures seamless scaling and zero-downtime rolling updates in Kubernetes and Docker Compose for self-hosted Firecrawl deployments, as traffic will only be routed to healthy API instances.

Additional Context This resolves multiple TODO comments in the codebase regarding liveness and readiness checks.