[tech-debt] Centralize `/api/health` URL for FE Vercel migration

Follow-up from Wave 2a Cluster E1 (#219 connection-quality indicator). Code-quality reviewer flagged forward-compat concern.

Current state

app/src/components/ConnectionQualityIndicator.tsx:11 hardcodes the ping endpoint:

```ts
const ENDPOINT = '/api/health'
```

Today the FE is served from the same VPS as the agent at sipher.sip-protocol.org, so the same-origin /api/health request reaches the backend. Works.

Future risk

Per ~/.claude/projects/-Users-rector-local-dev-sip-protocol/memory/project_fe-vercel-migration.md, the SIPHER FE is planned to migrate to Vercel. After migration, the FE serves from *.vercel.app while the backend stays at sipher-api.sip-protocol.org. A relative /api/health request from the Vercel-served FE will:

• Hit Vercel's 404 (FE host has no /api/health route)
• Indicator perpetually shows red
• Misleading UX (backend is fine; the URL is just wrong)

Proposed fix

Centralize the backend base URL. Either:

• Use an existing apiFetch helper if one provides a base URL abstraction (check app/src/api/client.ts)
• Or expose import.meta.env.VITE_API_BASE (already used elsewhere for API calls) and build ${API_BASE}/api/health

Audit other hardcoded /api/* URLs in app/src/components/ and app/src/views/ for the same risk.

Source

Wave 2a Cluster E1 code-quality review minor finding #6.

Priority

Low — works correctly today. Becomes Important when Vercel migration starts.

Start with app/src/components/ConnectionQualityIndicator.tsx:11 and inspect app/src/api/client.ts, then search app/src/components/ and app/src/views/ for hardcoded /api/* URLs. Check how VITE_API_BASE is already used elsewhere and centralize the health request through the existing URL approach. Done means the indicator uses the backend base URL and the frontend API URL audit is addressed without breaking current same-origin behavior.