GET /api/project-health reports status:healthy with -1 node/edge counts on a store missing its tables

[AmirF194]

Version: built from source, HEAD 59a05eb
Platform: Linux (x64)
Install channel: Built from source
Binary variant: ui

What happened, and what did you expect?
GET /api/project-health always answers status: healthy, even when the project's nodes/edges tables can't be read. It calls the same cbm_store_count_nodes/cbm_store_count_edges functions handle_index_status uses, but never checks the result before writing it into the reply, so a broken store comes back as {"status":"healthy","nodes":-1,"edges":-1,...} instead of something that says the read failed.

Reproduction

1. Build a normal project store (cbm_store_open_path + a couple of rows), then simulate corruption: sqlite3 proj.db 'DROP TABLE nodes; DROP TABLE edges;'.
2. GET /api/project-health?name=proj
3. Actual: {"status":"healthy","nodes":-1,"edges":-1,"size_bytes":...}. Expected: a non-healthy status, the way fix(store): report a failed COUNT read instead of returning zero #2065 handles the same failure for index_status.

I didn't drive this through the live HTTP endpoint end to end. I reproduced the exact call sequence handle_project_health makes, cbm_store_open_path_query then cbm_store_count_nodes/cbm_store_count_edges on a store whose nodes/edges tables were dropped, in a test added to test_store_nodes.c, and got -1/-1 (CBM_STORE_ERR) for both. handle_project_health (src/ui/http_server.c:1347-1374) writes those ints straight into the JSON reply with no check.

#2065 is already open for the identical gap in handle_index_status (mcp.c), adding a nodes < 0 || edges < 0 guard there. That PR doesn't touch http_server.c, so this endpoint is still open to the same false-healthy report. Happy to send a PR for the http_server.c side too, once I've got a free PR slot on this repo.

Confirmations
Searched existing issues, no duplicate found. Repro is code-only (no proprietary snippet).