Update commitment schedule

Required. When true, extend or shorten step-linked base BTs (and their POBs) to match the new schedule endDate, plus resync container BT dates. When false, the schedule mutates alone and the caller is responsible for BT realignment.

New schedule end date (YYYY-MM-DD, inclusive). Only valid on the LAST schedule of the commitment (changes on earlier schedules would break contiguity). Must be ≥ the end of the latest commitment period on this schedule that has a non-voided invoice, and must align with a period boundary of every linked base BT’s billing cadence. When composed with startDateChange on a single-schedule commitment, this value wins as the final absolute endDate (applied after startDateChange).

Optional start-date mutation. When present, only valid if the URL scheduleId is the FIRST schedule of the commitment (min sequence). mode: extend mutates only that schedule’s startDate; blocked if it would cross a period that has a non-voided invoice. mode: shift translates every schedule and every commitment period by the delta; blocked entirely if any non-voided invoice exists anywhere on the commitment. When cascadeBillingTerms=false, both modes must align with linked base BT billing-period boundaries (the BT grid stays put); when cascadeBillingTerms=true, the BT grid re-anchors to the schedule’s new start, so alignment against the old anchor is not enforced. With cascade: extend moves linked base BTs’ startDate + attached POBs’ serviceStartDate to match the schedule’s new start; shift translates every linked base BT and container BT (both edges) and every attached POB (both service edges) by the same calendar delta.

New cadence for the schedule’s commitment periods. Rejected if any period on this schedule already has a non-voided invoice, or if the schedule is multi-step (invariant #7: multi-step schedules must be full-duration).

New prepayment schedule type. Rejected if any period on this schedule already has a non-voided invoice.

Per-step billing term additions. Each element is { [stepId]: btId[] }. All steps must end with the same event-type set (invariant #6). Only base BT links (billingTermCommitmentType=null) can be added here.

Per-step billing term removals. Each element is { [stepId]: btId[] }. The BT must currently be linked as a base BT on that step.