Bug: API routes silently masking database errors with 200 OK responses

[ArshVermaGit]

Description

Several backend API routes are currently catching database connection or query failures and silently swallowing them. Instead of propagating the error or returning an appropriate HTTP 500 Internal Server Error status, these endpoints return a 200 OK status with empty or fallback data.

For example, endpoints like /api/local-coding-stats and /api/user/settings fail silently when the Supabase database is unreachable, responding as if the request succeeded. This fundamentally breaks error handling on the frontend (since fetch requests interpret the 200 as a success) and makes debugging backend issues incredibly frustrating.

Expected Behavior

• Any unhandled exceptions or database connection failures within an API route should result in a 500 Internal Server Error response.
• The frontend should be able to appropriately catch these non-2xx responses and display a meaningful error message to the user (or trigger retry logic).
• API routes should only return 200 OK when the underlying operation (like fetching or updating user settings) has verifiably succeeded.

Steps to Reproduce

1. Intentionally break the local database connection (e.g., provide an invalid SUPABASE_URL or stop the database service).
2. Attempt to fetch local coding stats by calling /api/local-coding-stats or try to update user settings.
3. Observe the network tab: the request returns a 200 OK with an empty object or null data.
4. Run the API test suite (npm run test test/local-coding-stats.test.ts) which asserts and exposes this exact improper behavior.

Suggested Fix

1. Audit the catch blocks within the src/app/api/ routes.
2. Replace returns like NextResponse.json({ data: [] }, { status: 200 }) inside catch blocks with NextResponse.json({ error: "Internal Server Error" }, { status: 500 }).
3. Update the associated unit tests to assert that a 500 status code is returned on database failures.