Worker and scheduler readiness reflecting consumer state

[FullFran]

Kubernetes needs liveness and readiness to be distinguishable, and they are not
the same signal. Right now neither exists as a dedicated endpoint.

Why they differ here

• Liveness — the process is not deadlocked. Restarting fixes it.
• Readiness — this instance can serve or consume right now. Postgres and
  Redis are reachable. Restarting does NOT fix a dependency being down, so a
  failing dependency must fail readiness and NOT liveness. Getting this
  backwards produces restart loops during a database blip, which is one of the
  most common self-inflicted Kubernetes outages.

Scope

• GET /healthz — liveness. No dependency checks. Must stay cheap
• GET /readyz — readiness. Checks Postgres and Redis connectivity
• Equivalent probes for worker and scheduler, which have no HTTP server
  today. Decide between a minimal probe server and a file-based liveness marker
• Graceful shutdown on SIGTERM: stop accepting work, drain the in-flight
  BullMQ job, then exit. Kubernetes sends SIGTERM on every rollout, so
  without this every deploy drops jobs
• Document the chosen terminationGracePeriodSeconds and why

Definition of done

Killing Postgres makes readyz fail while healthz stays green, and the pod is
removed from the Service endpoints without being restarted.

[FullFran]

Audited the codebase before starting: most of this already exists and this issue was written without checking. Correcting the record.

Already implemented:

Item	Where
/health liveness	src/modules/observability/health.controller.ts
/ready readiness	same, backed by ReadinessService — resolves the base schema through search_path rather than pinning public
enableShutdownHooks	src/main/worker.ts, api.ts, scheduler.ts
SIGTERM/SIGINT handling with a force-exit deadline	src/main/bootstrap-guards.ts, SHUTDOWN_TIMEOUT_MS
Graceful drain	onApplicationShutdown on all four queues, all four workers and the Postgres pool
Worker metrics server	src/main/worker-metrics-server.ts, port 3001

What actually remained was wiring these into Kubernetes, which is in #25.

Genuinely still open, and narrower than this issue claimed:

• Worker readiness reflecting consumer state. The worker has no HTTP API, so feat(k8s): Kubernetes manifests for the three runtimes #25 probes TCP against the metrics port. That proves the process is up; it does not prove the BullMQ connection is alive. A worker whose Redis connection dropped while the metrics server stayed up would pass the probe.
• Scheduler has no probe target at all — decide between a minimal probe server and a file-based liveness marker.

Retitling the remaining work rather than closing, since the gap above is real.