fix: harden API response error handling

[gtmdev-br]

Summary

Harden the shared frontend API client so non-2xx HTTP responses are rejected as errors instead of flowing through as successful ApiResponse<T> values. This ensures error interceptors (401, 429) fire reliably and callers no longer need to duplicate status checks.

Changes

• Added parseErrorResponse() — safely parses JSON and text error response bodies into ApiError objects, preserving requestId, details, path, and actionable suggestion fields.
• Modified request<T>() — checks response.ok after fetch; non-2xx responses are parsed, run through the error interceptor chain, and thrown immediately (bypassing retry logic since HTTP errors are deterministic).
• Added isApiError() type guard — distinguishes our ApiError objects from native Error types (DOMException, TypeError) to prevent false positives in the retry logic.
• Added validation test suite — 8 tests covering: 200 OK success, 401 JSON error, 429 rate-limit, 500 text error, 404 not-found, error interceptor execution, timeout (408), and network failure.
• Included diagnostic build artifact — diagnostic/build-c6be4f51.json

Testing

• npx tsc --noEmit — passes (zero errors)
• npm run build — builds successfully
• npx tsx src/services/__tests__/api-error-handling.test.ts — 8/8 tests pass
• Verified: 2xx returns ApiResponse, 401/429/500/404 throw ApiError with correct codes and suggestions, error interceptors fire, timeout returns 408, network errors handled

Checklist

• Frontend module builds locally
• Validation tests pass locally
• Diagnostic build log is committed in this PR
• Changes are scoped to the PR purpose
• Security, privacy, and error-handling implications have been considered

Closes #1