Task status vocabulary mismatch with the API: every task lands in To Do, and Start marks tasks complete

[manjula25]

Summary

The frontend maps task statuses using a vocabulary that never occurs on the wire — the API returns display strings ('Open', 'In progress', 'Done', 'Cancelled', 'Deferred' via displayStatus() at apps/api/src/fhir/client.ts:246), but the UI checks FHIR codes. Every task lands in "To Do", the other tabs are permanently empty, and the "Start" button actually completes the task.

Evidence

apps/web/src/pages/TaskManagement.tsx:22-26:

function toTabStatus(status: string): TabStatus {
  if (status === 'in-progress') return 'in_progress';       // never on the wire
  if (status === 'completed' || status === 'cancelled') return 'completed';  // never on the wire
  return 'pending';
}

TaskManagement.tsx:41-45 + line 233 — the "Start" button sends transition: 'complete':

const PRIORITY_TO_TRANSITION = { pending: 'complete', in_progress: 'complete', completed: 'complete' };
...
onClick={() => transitionTo(task.id, PRIORITY_TO_TRANSITION.pending)}  // "Start" ⇒ completes

Also apps/web/src/pages/TaskQueue.tsx:135,211 checks task.status === 'In Progress' (capital P) against the backend's 'In progress' — the "In Progress" chip and filter tab are dead. The fixtures (TaskQueue.fixtures.ts:35) use the wrong 'In Progress' too, so tests mask it; MOCK_TASKS in demoFallbacks.ts uses a third vocabulary ('requested'/'in-progress') which breaks isOpenStatus's 'Done' check in fallback mode.

Impact

• Every task — including completed ones — appears in the "To Do" tab; "In Progress" and "Completed" tabs are always empty.
• A coordinator clicking "Start" on a task marks it Done.
• The optimistic update (line 87) writes raw 'completed'/'requested' into the cache, so after refetch the task visibly flip-flops tabs.