Failed writes reported as success: CarePlanBuilder posts to the wrong origin; TaskManagement keeps optimistic state on API failure

[manjula25]

Summary

Two pages report success to the user when the server write failed — in CarePlanBuilder's case the write fails even when the API is fully up, because it POSTs to a relative URL on the Vite dev origin instead of the API base URL.

Evidence

apps/web/src/pages/CarePlanBuilder.tsx:111-123 — a raw fetch('/api/care-plans/...') while every other call goes through apiFetch (api/client.ts), which prefixes API_BASE_URL (default http://localhost:4000); vite.config.ts has no dev proxy, so the POST 404s on the Vite origin and lands in the catch:

const res = await fetch(`/api/care-plans/${encodeURIComponent(patientId)}`, { ... });
...
} catch {
  setToast('Care plan saved (offline)');
}

The coordinator sees a success-styled toast while the CarePlan was never written to HAPI (the real endpoint exists at apps/api/src/routes/carePlans.ts). It also bypasses apiFetch's 401-logout handling.

apps/web/src/pages/TaskManagement.tsx:93-99 — same pattern: on API failure the optimistic (unverified) state is kept and 'Task updated (offline)' is toasted. Unlike TaskDetail.tsx, which surfaces transitionError with role="alert", this page silently fakes completion.

Impact

A care coordinator believes a clinical care plan or task transition was saved when nothing reached the server — in a care-coordination tool that is a real patient-safety failure mode.