Harden API response error handling for non-2xx status codes

[GautamKumarOffical]

Summary

Fix request<T>() so non-OK HTTP responses are rejected instead of being silently returned as successful ApiResponse<T> values. This ensures error interceptors (401, 429, etc.) actually fire and callers get structured ApiError objects with message, details, requestId, and suggestion fields.

Changes

• Added parseErrorResponse() that safely parses JSON and text error bodies into ApiError objects
• Added ApiHttpError class extending Error that wraps ApiError and serializes back to JSON
• Modified request() to check response.ok after fetch — non-2xx responses now throw through the error interceptor chain
• Error interceptors (including the default 401/429 handlers) now reliably execute for HTTP errors
• Timeout and network-error paths (normalizeError) remain unchanged
• Added vitest with 10 tests covering 2xx success, 401 JSON error, 429 rate-limit, 500 text error, timeout abort, network error, error interceptor execution, and POST non-retry behavior

Testing

• npm run test — 10/10 tests pass
• npx tsc -b — TypeScript compiles clean
• python3 build.py -m frontend — frontend build passes
• Diagnostic logd artifact committed in this PR

Checklist

• Relevant modules affected by these changes build locally
• Tests pass locally
• Diagnostic build log is committed in this PR
• Documentation has been updated, if applicable
• Configuration or schema changes are documented, if applicable
• No generated build artifacts are committed, except the required diagnostic build log
• Changes are scoped to the PR purpose and avoid unrelated cleanup
• Security, privacy, and error-handling implications have been considered

---

• I would like to request that my diagnostic build log is removed before merging