fix(stats): do not hide metadata query failures as successful zero counts #49

Finding

GET /admin/api/stats turns relational query failures into successful zero counts. Missing/broken application metadata is indistinguishable from a healthy, empty index in the dashboard and API.

Related reproducer: #45. Fixing selected-database access does not eliminate the need to distinguish failed queries from legitimate empty results.

Observed evidence

At source revision 41ec093a745f1c0277893dc8f758b96b216c970f, an isolated full-PostgreSQL deployment initialized its PostgreSQL schema and healthy pgvector backend, but legacy metadata queries opened an empty SQLite database.

Authenticated /admin/api/repos returned HTTP 500 with no such table: git_repositories logged. Indexing and polling also logged missing-table failures.

In the same state, authenticated GET /admin/api/stats returned HTTP 200:

{
  "files_count": 0,
  "git_repos": 0,
  "local_paths": 0,
  "total_symbols": 0,
  "total_routes": 0,
  "total_relationships": 0,
  "vector_db_status": "Healthy"
}

These zeros are not successful count-query results: the local _count() helper catches every query exception and returns 0.

Expected outcome

• Distinguish genuine zero counts from failed/unavailable counts.
• Required relational query failures should produce the API's explicit error response, or a deliberately documented degraded result with unavailable counts and visible error state; do not silently substitute zero.
• Log useful, sanitized diagnostics and make the failure visible to the dashboard.
• Do not report the entire application as healthy just because its vector backend is healthy.

Acceptance checks

• A healthy, empty database still returns successful zero counts.
• Missing-table and database-unavailable/query-failure tests do not return success-shaped zero counts.
• The PostgreSQL reproduction from fix(database): unify PostgreSQL selection with legacy indexing connections #45 surfaces metadata failure in this endpoint.