fix(api): sanitize unhandled API error messages, add Sentry request context (#579)

[eleven-smg]

Closes #579

What

Unhandled API responses previously rejected with the raw AxiosError, whose message/config can embed the full request URL. This adds a dedicated sanitization layer so the UI only ever sees a generic, URL-free message, while the full url + method are sent to Sentry request context for debugging.

Changes

• New src/services/api/errorSanitization.ts — pure helpers: getSafeErrorMessage, containsUrlOrPath, sanitizeErrorMessage, buildSanitizedApiError (+ SanitizedApiError type).
• New src/services/api/__tests__/errorSanitization.test.ts — 30 tests covering every 4xx/5xx status, URL/path stripping, and payload shape.
• Edit src/services/api/axios.config.ts — the default fallback now captures the request context to Sentry and rejects with a sanitized error.

Notes on the issue text

• The issue references apiService.ts, which doesn't exist in the current codebase; the relevant flow lives in axios.config.ts, which is what I changed.
• The issue suggests sentryContextService.setContext('request', …), but that method doesn't exist on the service. I used the real API: captureException(error, { contexts: { request: {…} } }).
• I did not add an error.userMessage field — all .message paths are already sanitized and no consumer reads userMessage. Happy to add it if you'd prefer strict adherence to the issue wording.

Verification

• npm test -- src/services/api/__tests__/errorSanitization.test.ts → 30/30 passing.
• eslint + prettier clean on the changed files.

[drips-wave]

@eleven-smg Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project.