Feature/db health check

[Keengfk]

Summary

/health previously only reflected process liveness. Once the app has a real
PostgreSQL dependency (issue #36), a healthy process with an unreachable
database would still return status: "ok" — misleading for operators and
alerting systems. This PR adds a db field to the health response that reports
connectivity independently of process health, with graceful degradation so the
endpoint always responds even when the database is down.

───────────────────────────────────────────────────────────────────────────────

Changes

src/health/database-health.service.ts (new)
Probes the database using PrismaService.$queryRaw\SELECT 1`` — this exercises
the real connection pool rather than a separate client. The query races against
a 3-second timeout. The method never throws; callers always receive a typed
result:

{ status: "ok", latencyMs: number } // database answered in time
{ status: "unreachable", error: string } // query failed or timed out

src/health/health.controller.ts (modified)
check() is now async and includes the db result in every response:

{
"status": "ok",
"service": "vortex-backend",
"version": "0.1.0",
"network": "stellar-testnet",
"uptime": 42.3,
"db": { "status": "ok", "latencyMs": 2 }
}

When the database is unreachable:

{
"db": { "status": "unreachable", "error": "Can't reach database server at
localhost:5432" }
}

src/health/health.module.ts (modified)
Provides DatabaseHealthService. PrismaModule is already @global() so no
additional import is needed.

───────────────────────────────────────────────────────────────────────────────

Design decisions

• Never returns a non-200 status — the process itself is healthy even if the DB
  is down. Consumers (load balancers, uptime monitors) that key off HTTP status
  are unaffected; richer monitors can inspect the db.status field.
• Timeout is fixed at 3s — long enough to avoid false positives on slow
  connections, short enough to keep the health endpoint responsive. Can be made
  configurable via AppConfig in a follow-up.
• Uses the existing Prisma connection pool — no second connection string, no
  separate pg client. Pool config comes from DATABASE_URL in AppConfig/env,
  consistent with the pattern used by stellar.sorobanRpcUrl.

───────────────────────────────────────────────────────────────────────────────

Testing

src/health/database-health.service.spec.ts (new) — 4 unit tests with a mocked
PrismaService:

• Query succeeds → status: "ok", latencyMs is a non-negative number
• Query rejects → status: "unreachable", error message captured
• Query hangs past timeout (fake timers) → status: "unreachable", error matches
  /timed out/i
• $queryRaw missing entirely → never throws, returns status: "unreachable"

test/health.e2e-spec.ts (updated) — asserts the db field is always present and
structurally valid for both the ok and unreachable branches. The e2e suite runs
with the mock PrismaService (no real DB), which exercises the
graceful-degradation path.

npm run lint ✓ 0 errors
npm run typecheck ✓ 0 errors
npm run build ✓ clean
npm test ✓ 39 tests, 6 suites (+4 new)
npm run test:e2e ✓ 23 tests, 5 suites

closes #58

[drips-wave]

@Keengfk Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits