feat(api): implement 403, 429, and 500+ error handling with exponential backoff

[Shadow-MMN]

Closes #53

---

Description

This PR enhances the API error handling in axios.config.ts to improve resilience and user experience. It adds specific handlers for forbidden access, rate limiting, and server-side errors.

Changes

• 403 Forbidden: Added custom rejection with a clear access-denied message.
• 429 Rate Limiting: Implemented exponential backoff with a maximum of 3 retries.
• 500+ Server Errors: Added a retry mechanism (max 2) before returning a user-friendly fallback message.
  Utility: Integrated a getBackoffTime helper for consistent delay calculations.

Verification Results

• Verified that 403 errors trigger the correct rejection logic.
• Verified 429 errors trigger retries with increasing delays (1s, 2s, 4s).
• Verified 500+ errors perform limited retries to mitigate transient server blips.

Existing Issues & Observations

• During local testing (npm run test), I observed that the pushNotifications service tests and utility handlers are currently failing due to TypeScript mismatches (likely caused by a recent expo-notifications version update).
• The Issue: NotificationTriggerInput is missing the required type property in test mocks, and removeNotificationSubscription is missing from the mock type.
• Volunteer Offer: I am happy to fix these test failures and type issues! If the maintainers create an issue for "Fix Notification Type Mismatches," I'd love to take it on as my next contribution.

Suggestions for Further Enhancement

Based on my review of the codebase, here are a few low-hanging fruits I'd recommend:

• Offline Request Queueing: Currently, network errors are just logged. We could implement a simple queue to retry failed GET requests once the useNetworkStatus hook detects the device is back online.
• Global Error Toast Integration: Instead of just rejecting with a message string, we could integrate the apiClient with a global toast/notification store to show these user-friendly messages automatically to the user.
• Session Auto-Refresh: The isSessionValid utility in secureStorage.ts could be used in a background timer/hook to refresh the token before it actually expires,reducing the latency caused by the 401 interceptor trigger.

[drips-wave]

@Shadow-MMN 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]

kindly resolve conflict

[Shadow-MMN]

kindly resolve conflict

ok so sorry just seeing this now

[Shadow-MMN]

@RUKAYAT-CODER please check them out now