feat(health): bounded DB connectivity check on /health

[AquiGorka]

What

`/api/v1/health` now runs a 2s-bounded `SELECT 1` against the app `PgPool` and reports `deps.db`:

• 200 `{ status: "ok", version, deps: { db: "ok" } }` when Postgres answers.
• 503 `{ status: "error", version, deps: { db: "error" } }` when the DB is unreachable or unresponsive (timeout).

The existing `status`/`version` fields are preserved.

Why

A static `{status:"ok"}` health endpoint masked a dead DB during a prod incident. The SaaS provider-platform + council-platform already gained a DB-aware `/health`; this brings the Rust provider-stand-in to parity, mirroring the Deno `checkDbHealth` reference (`src/http/v1/health/db-check.ts`).

Design

• Connectivity-only: `SELECT 1` checks that a connection can be established; it does not depend on migrated schema, so a still-migrating boot with a reachable Postgres still reports `db:ok`.
• Timeout-bounded (`tokio::time::timeout`, 2s) — kept well under the container/compose healthcheck `timeout` so a slow/unreachable DB resolves to a fast 503 instead of hanging the health gate.
• Single-PP semantics untouched.

Tests (`crates/api/tests/health_http.rs`)

• `health_reports_503_when_db_unreachable` — lazy pool pointed at an unreachable port; no live DB needed.
• `health_reports_200_and_db_ok_with_live_db` — per-test migrated DB (skips with an `eprintln` when `DATABASE_URL` is unset).

Both verified locally against an isolated throwaway Postgres; the DB-down path also runs without any DB.

Version

Workspace `0.1.0` -> `0.2.0`.