Save draft edits to validation-failed roster rows

Applies corrections to a batch of roster rows and stores them as an in-progress draft.

When to use: call this after reviewing validation errors, to record proposed fixes before asking for the roster to be checked again; follow it with POST /roster-records/{rosterId}/revalidate when the corrections are ready to be re-run.

Preconditions: supply the tenant-id header and the rosterId of an existing roster job. Only rows currently in VALIDATION_FAILED state can be drafted; every entry in rows must set recordKey to the rowId of a row in that roster, obtained from the roster row listing endpoints. Each entry's rowData is merged into the stored row one level deep - top-level keys you supply replace their stored counterparts, keys you omit are left untouched, and nested objects are replaced wholesale rather than merged. The batch is limited to 100 entries by default; a larger batch is rejected with 400 and should be split.

Partial success: entries are processed individually, so one bad entry does not discard the rest. An entry is reported as a failure - and the others still saved - when its recordKey matches no row in the roster, when its rowData is not a JSON object, or when the target row is not in VALIDATION_FAILED state. Always read failures in the response rather than relying on the HTTP status alone. What you get back: succeeded, the number of rows saved, and failures, one entry per rejected row with the recordKey and the reason.

Side effects: each saved row is marked as drafted and its payload is appended to that row's draft history, so this operation is not idempotent - submitting identical edits twice appends two history entries. Row status is left at VALIDATION_FAILED; rows are not revalidated until you call the revalidate endpoint.