feat: typed api client and api key handling

[Scr4tch587]

What changed

• `src/lib/api.ts`: typed fetch client for `/api/v1` — `DatasetSummary`/`DataRow`/`DataResponse` interfaces, `ApiError` carrying the HTTP status, `Authorization: Bearer` header attached automatically when a key is stored. `fetchData` accepts both 200 and 206 (partial data) and always sends `build-data=false`, matching the old frontend. Base URL is `VITE_API_BASE_URL` when set (Pages build) or relative for the Vite dev proxy
• `src/lib/api-key.ts`: key storage in `localStorage` under `datastream.api_key` + masked display helper
• `src/hooks/use-api-key.tsx`: `ApiKeyProvider` context; the key dialog auto-opens on first load when no key is stored (the backend rejects everything except `/status` without one)
• `src/components/api-key-dialog.tsx`: shadcn Dialog + Form with zod validation (`dsk_` prefix), masked view of the stored key with a clear button
• `src/main.tsx`: TanStack Query client — a central `QueryCache.onError` turns any 401 into a toast + reopens the key dialog; retries skip 401/403/404; saving a key invalidates all queries so they refetch immediately
• `src/lib/format.ts`: direct ports of `toISODate` / `defaultDateRange` (5-year window) / `formatTimestamp`

Why

The backend requires an API key on all endpoints except `/status`, and the GitHub Pages build is a static cross-origin site with no server to inject one. The key is pasted by the user and lives only in their browser.

Benefit

Every request is authenticated with zero per-component ceremony, and auth failures funnel to a single recovery path (toast → dialog). The browsing UI in the next PR consumes this client directly.

🤖 Generated with Claude Code

[github-actions]

• main
  • feat: replace svelte frontend with react + tailwind scaffold #375
    • feat: typed api client and api key handling 👈
      • feat: dataset browsing ui #377
        • ci: deploy frontend to github pages #378
          • docs: update specs for react migration #379