feat(backend): expand health checks with liveness, readiness, dependency probes (#353)

[prissca]

Summary

• GET /health/live: alias for GET /health's process-only liveness check (same handler, matches the issue's requested route name).
• GET /health/ready: extended from checking only the tasks/payments DBs to also check the job queue DB, the Venice AI and Stellar Horizon providers, and (if attached) the WebSocket stream server — {tasks, payments, queue, venice, horizon, websocket}. Fails (500) when any dependency is down. The one exception: a WebSocket probe that was never registered reports "unknown" (a valid configuration — the stream layer may simply not be attached, per the existing convention in services/metrics.ts) and does not by itself fail readiness; a probe that is attached and reports not-listening does fail it, same as every other dependency.
• MetricsService.getWebSocketStatus(): a small new public method exposing the existing (private) checkWebSocket() probe, so /health/ready can read live WebSocket status without a full dashboard collection.
• New HEALTH_PROBE_TIMEOUT_MS config field (default 5000ms) — the configurable threshold the issue asks for, used by both /health/deep's and /health/ready's provider timeouts (previously hardcoded to 5000).

Necessary prerequisite: several backend files were corrupted by a bad merge

package.json, jest.config.js, tsconfig.json, config/index.ts, api/app.ts, api/routes/stream.ts, api/routes/agents.ts, and api/routes/stats.ts each contained two full, conflicting versions of their own content concatenated together — duplicate imports/declarations, or (for the route files) an entire stale stub implementation glued in front of the real one. This blocked npm install/npm test entirely.

Same root cause and fix pattern already documented in Epta-Node/ai-net#443 (a different fork of this repo hitting the identical corruption in package.json/jest.config.js/tsconfig.json/api/app.ts for issue #359): in each file, kept the newer half whose imports/exports/fields actually match what the rest of the codebase references (e.g. agents.ts's real createAgentsRouter() uses the DB-backed AgentDb, not the old in-memory stub; stats.ts's real createStatsRouter() uses the DB-backed StatsCache), discarded the stale duplicate, and restored two things that were missing outright: stream.ts's activeStreamServers Set + getStreamConnectionCount() export (referenced by api/app.ts but never defined), and agents.ts's RegisterAgentSchema (referenced by the register route, mirroring the RegisterAgentRequest schema already documented in api/docs.ts).

This PR's app.ts fix is the minimal corruption fix only — it does not include the close()/job-worker-drain changes from the related #349 work, to keep this diff scoped to health checks.

Full backend test suite: 46/51 suites passing after these fixes (up from 5 suites failing to even compile before them). The remaining 5 failing suites (tests/tasks.test.ts, api/routes/agents.test.ts, registry/sync.test.ts, api/middleware/versioning.test.ts, cache/cache.test.ts) fail for reasons unrelated to health checks — error-response-shape mismatches, a @stellar/stellar-sdk/rpc module resolution issue, and fake-timer flakiness — pre-existing and out of scope here.

Acceptance Criteria

• Readiness fails when DB or provider is unavailable
• Payload lists each dependency with status

Test plan

npx jest src/api/routes/health.test.ts — 30/30 passing, including 6 new /health/ready tests (all six dependency keys present, Venice/Horizon failure fails readiness, websocket "unknown" doesn't fail readiness on its own, websocket "unreachable" does) and 1 new /health/live test.

Closes #353

[drips-wave]

@prissca 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

[vercel]

@Obiajulu-gif is attempting to deploy a commit to the Jaja's projects Team on Vercel.

A member of the Team first needs to authorize it.