Re-trigger validation or ingestion for a roster job

Queues the validation or ingestion stage again for a roster job that already exists.

When to use: call this as a recovery step when a roster has stalled because its processing event was lost, and you need to nudge the pipeline without creating a new job. To submit a corrected file instead, use PUT /roster/{rosterId}/reupload.

Preconditions: supply the tenant-id header and set eventType in the path to either validation or ingestion; the value is matched case-insensitively and anything else is rejected with 400. The request body must carry rosterId, identifying an existing roster job. Only rosterId is read from the body - the tenant is taken from the header, and the acting user from the roster's own record, so any tenantId or userId sent in the body is ignored.

State guard: the stage must still be meaningful for the job. Re-queuing validation on a roster that is already VALIDATED, or ingestion on one that is already COMPLETED, is rejected with 400 naming the current status rather than silently doing nothing.

What you get back: a short confirmation object echoing the event type that was queued. The work itself runs in the background, so poll the roster job to observe progress.

Side effects: a processing event is queued. Not idempotent while the roster remains in a re-processable state - repeated calls queue repeated runs.