Normalize API HTTP errors

[felixvippp-ai]

Summary

Closes #1
/claim #1

Payment address (USDC on Base): 0x1aba67a6f349826fbaea17f54556a42d42399474

Normalize the shared frontend API client so non-2xx HTTP responses reject as structured ApiError values instead of flowing through as successful ApiResponse<T> data. This preserves backend error details while keeping timeout and network-error handling on the existing normalization path.

Changes

• Reject non-OK fetch responses before response interceptors run.
• Preserve JSON/text error bodies, status code, request ID, path, timestamp, details, and suggestions in ApiError.
• Route normalized HTTP errors through the existing error interceptor chain, including 401 and 429 handling.
• Add Vitest coverage for 2xx success, 401 JSON errors, 429 rate limits, 500 text errors, aborted requests, and network failures.

Testing

• npm test — passed, 1 test file / 6 tests.
• npm run build — passed, TypeScript build and Vite production build succeeded.
• python build.py -m frontend --verbose — attempted after the local commit, but this Windows environment blocks in the repository's bundled encryptly preflight before the frontend module build starts, so it did not produce a usable diagnostic .logd. The frontend-specific verification above passed.

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