Execute an action on a leg. Three actions are supported, discriminated on type.

The two recovery actions are gated differently — retry on the LEG's state, return on the LOAD's:

• retry reopens a load-failure Failed leg for a fresh delivery attempt: every load on the leg re-runs (its load stays with the leg, the failed status clears, and the shipment un-fails so the cargo can be routed onto a new tour). An optional re-attempt delivery window may be supplied. Because the whole leg re-runs, retry is illegal on a Delivered leg with a partial failure (one load failed while a sibling delivered) — recover that load via return instead.
• return sends one recoverable failed load back to a chosen destination. It spawns a new return shipment that picks the load up at its current custody position and delivers it to the target; the original load is retired and linked to the return shipment so it is never planned again. It is legal wherever a load needs recovery: on a load-failure Failed leg, on a Delivered leg with a partial failure, and on a Cancelled leg holding cargo a completed predecessor stranded at a hub.

The metadata action is legal in any leg state:

• set-properties merges tenant-defined custom-property values into the leg's existing properties (a null value clears that property; absent keys are left untouched). It has no effect on the leg's lifecycle. Values are validated against the property definitions scoped to leg; unknown ids or type mismatches are rejected with 400.