Configure API service layer with Axios, interceptors, and error handling #17

📋 Description

Set up a robust HTTP client layer to standardize calls to apps/api and error behavior.

Scope correction: apps/api has no auth awareness (no endpoint currently requires a token — see docs/architecture-decisions.md). This layer does not inject any auth header. Session/token handling for Firebase-backed features is entirely delegated to the Firebase SDK (see #65), never routed through this Axios layer.

Centralized Axios instance for all apps/api calls. Auth token comes from Firebase SDK and is attached via an interceptor — no login or refresh routes exist in apps/api. All feature work is built against a typed mock layer until backend integration in week 7.

Mocked endpoints to define
GET
/v1/zones/at-risk?bbox=&limit=&offset=
map + risk list
GET
/v1/zones/{zone_id}?from=&to=
detail + history
GET
/v1/dashboard/kpis?bbox=&period=
dashboard
GET
/v1/zones/compare?zone_ids=&indicators=&period=
analysis
POST
/v1/zones/export/pdf
export

✅ Acceptance Criteria

• Axios instance is centralized.

• Response interceptor handles common API error formats.

• Error normalization strategy is documented.

• Axios instance reads base URL from VITE_API_URL

• Request interceptor attaches Firebase JWT (getIdToken()) to every request

• Response interceptor normalizes error shapes (400/404/500)

• Typed mock layer at src/api/mocks/ mirrors every endpoint above with realistic data

• Mock layer toggled via VITE_USE_MOCKS=true — no mock code in production bundle

• No login/register/logout/refresh routes through Axios — Firebase handles all of this

🔗 Prerequisite Issues

DoD

• At least one sample API call uses the service layer.
• No direct raw Axios usage in feature code for baseline flow.
• Error handling behavior is testable and predictable.
• API layer conventions are documented.