[Roadmap] Multi-leg order coordination and recovery

Problem

Submitting pair or basket legs as independent orders creates legging risk, partial-fill exposure, duplicate-order risk, and difficult restart recovery.

Desired outcome

Add a durable multi-leg execution coordinator that makes state and recovery explicit while respecting each broker's actual capabilities.

Initial scope

• Persist a parent execution intent and child leg state machine.
• Define sequencing, parallel submission, timeout, cancel, retry, and compensation policies.
• Reconcile partial fills and unknown broker states after restarts.
• Enforce idempotency and expose operator-visible diagnostics.
• Allow venue-native combination orders through broker capability adapters when available.

Acceptance criteria

• An RFC defines state transitions and invariants.
• Tests cover first-leg failure, second-leg failure, partial fills, timeout, process crash, and duplicate delivery.
• Recovery never silently discards unmatched exposure.
• Logs and metrics expose parent and leg identifiers.
• Paper adapters can deterministically simulate failure cases.

Out of scope

• Advertising atomic fills on venues that only accept independent orders.
• Broker-specific behavior in HTTP routes or the generic strategy runtime.

Contributing

This work is execution-critical. Comment with a narrowly scoped state-machine, adapter, fixture, metric, or documentation task. Maintainer agreement is required before implementation.