feat(api,gateway): add all-or-nothing bulk remote assignments

[thomasbeaudry]

Backend for group-scoped bulk remote assignments (#1500), following the review on that issue.

A front-end PR follows once this is approved. It builds directly on these contracts, so it is kept separate to let the backend be reviewed and tested on its own.

What it does

POST /v1/assignments/bulk/preflight and POST /v1/assignments/bulk, both group-scoped.

A batch is N subjects × M timepoints: each (instrument, expiry) pair applies to every selected subject, so 50 subjects and 3 instruments create 150 assignments in one operation.

Following the review comments

• All-or-nothing. No per-row results. Preflight throws with every issue attached; create re-runs the same checks so a conflict appearing between review and submit cannot slip through, and any failure deletes every row the call staged.
• Non-2xx leaves everything as it was. The gateway writes its batch in a transaction; the API rolls back its own staged rows if that call fails.
• Preflight explains the problem. 422 with a typed body: CONFLICT, INSTRUMENT_UNAVAILABLE, SUBJECT_UNAVAILABLE.
• A conflict is an existing OUTSTANDING, unexpired assignment for that subject and instrument in that group. It blocks by default and is waived only by an explicit allowDuplicates.
• Each bundle is fetched and sent once per batch, not once per assignment.

SUBJECT_UNAVAILABLE deliberately does not distinguish a subject that does not exist from one outside the group, so the endpoint cannot be used to probe for subjects elsewhere.

Also in here

• A dynamic future-date schema. z.coerce.date().min(new Date()) froze its bound at module load, so a long-running API kept accepting expiries that had since passed. Now used by the single-assignment contract too.
• The gateway had no vitest project. Added, and the file is confirmed collected.
• The staged assignment no longer carries encryptionKeyPair. It was being serialized into the response and posted to the gateway; Assignment does not declare the field, but structural typing does not remove it at runtime.

Verification

446 unit tests plus 4 API-level Playwright tests covering real Mongo scoping, the real gateway round trip, and the all-or-nothing guarantee.

The e2e tests were checked against a mutant rather than trusted for being green: breaking the conflict query's status filter turns the repeat preflight from 422 into 200 and fails the suite.

Known gaps, deliberately left for discussion

• timepoints has no upper bound. subjectIds is capped at 500, but N×M means a group with many instruments can still make one request very large, and every assignment needs a keypair.
• The audit write sits outside the rollback. If it fails after a successful batch, the caller sees a 5xx while the assignments exist. Neither fix is obviously right: rolling back real assignments over a logging failure is bad, and so is an unaudited creation.
• Preflight skips the conflict query when a subject or instrument is already unavailable, so those are reported on a second round trip rather than the first.

🤖 Generated with Claude Code