e2e: worklist.spec.ts for the patient work list (Maui profile)

[Taleef7]

What

A Playwright spec for the patient work list, run under PLAYWRIGHT_PROFILE=maui alongside the existing pilot specs.

Named in the MM-2 plan under PR 1 and not built there. #551 shipped with 15 component tests over the page, which cover the logic but mount it against mocked API calls.

Why it is worth doing beyond the component tests

The component tests mock useApi, so they prove the page's behaviour given a response shape — not that the shape is the one the server actually sends. The three things they structurally cannot catch:

1. The response contract drifting. WorklistPatientRow is declared twice, once in backend-ts/src/case/worklist-patients.ts and once in the page. Nothing today fails if they diverge.
2. Authorization end to end. GET /api/worklist/** is AUTHENTICATED and POST /api/cases/bulk-assign is CM/ADMIN; only a real login exercises that pairing.
3. A router race the jsdom harness defines away. The nav mock updates params synchronously inside replace, so two payer checkboxes clicked before a re-render always see fresh state there. use-panel-payers's last-written-params ref exists for a race that only a real browser can produce — see the note in frontend/app/(dashboard)/worklist/page.tsx. A real click-click in Playwright is the only place that fix can be observed.

Worth covering

• One row per patient, every open gap on it, and the total counting patients not gaps
• Selecting patients and assigning all their open gaps in one request
• The insurance multi-select, including that "All Medicare" sends both 1 and 11
• A PCP filter round-tripping through the URL, so a filtered list is a shareable link

Context: #551, MM-2 plan PR 1 verification section.