feat(api): fan an apply out to one operation per rollout member

[aparajon]

Why this matters

An apply builds one operation per deployment and runs the apply's single plan on all of them. For an environment whose members were planned independently, that means every member runs the primary's DDL — DDL written for a different target's schema. This is the apply half of the multi-target contract: each member executes the plan it was actually planned from.

It also closes a latent collision that exists independently of the targets: spelling. The sharded operation group key was built from the deployment alone, so two members sharing a deployment would collide on a key and one member's work would be filed under the other's.

What it does

Resolves every rollout member to a plan before building operations, then keys the operations by member:

apply creation
  │
  ├─ mirrored     → every member runs the apply's plan
  │
  └─ independent  → primary runs the apply's plan
                    others run their own stored plan,
                    matched on the apply plan's head SHA

• Member plans are bound to a review round. A non-primary member's plan is looked up by member id and must carry the same head SHA as the apply's plan, so a plan produced for an earlier push of the same pull request is never picked up.
• A member with no plan for that round fails apply creation. There is no fallback to the apply's plan: it describes a different target's schema, so substituting it would run DDL that target was never planned for. A CLI apply against a multi-target environment fails here by construction, since it has no head SHA to match against — planning happens on a pull request.
• Operations are keyed by member, not deployment. A member is its deployment and target together, so two targets of one deployment each get their own operation for a given (namespace, shard, table) instead of one target's work being folded into the other's.
• A single-member apply short-circuits ahead of the contract lookup: it is the plan's own primary, runs the apply's plan either way, and has no sibling whose plan could be substituted — so apply creation does not require database config the trusted control-plane enqueue path is not given.

How it moves us toward the northstar

This is the step A4a's multi-target rejection was waiting on: the apply composer now consumes the full ResolveTargets result, dispatching one operation per member against the plan that member was planned from, instead of collapsing the result to a single route.

Opened by Claude (Fable 5).