Planner: multi-deploy chains for source-model/target-model endpoints (migrateProcessInstance, migrateProcessInstancesBatchOperation)

Symptom

Two endpoints in the bundled spec take a SOURCE process definition and a TARGET process definition as separate inputs in the request body and emit `mappingInstructions[].sourceElementId` referring to element ids in the source model:

Endpoint	Body field	Required source
`migrateProcessInstance`	`mappingInstructions[].sourceElementId`	Source process model
`migrateProcessInstancesBatchOperation`	`migrationPlan.mappingInstructions[].sourceElementId`	Source process model

PR #163 (PR 1 of #162) closes 4 of 7 ElementId gap entries, but these two are explicitly deferred. PR 1's `bindModelDerivedFromFixture` reads from the first `createDeployment` step's fixture, which is fine for endpoints with a single deployed model but misses the source-vs-target distinction.

A correct chain for either of these endpoints would be:

```
createDeployment (source model — e.g. simple.bpmn)
→ createDeployment (target model — must be a DIFFERENT bpmn — e.g. service-task.bpmn)
→ createProcessInstance (from the source model)
→ migrateProcessInstance (using mappingInstructions.sourceElementId from the source)
```

What's missing

Two coupled problems:

1. Multi-deploy chain construction. The planner today plans a single `createDeployment` step per scenario. A migration chain needs two — one each for the source and target models — and they need to deploy DIFFERENT BPMN fixtures (otherwise the migration is a no-op and the broker likely 4xx's).

2. Per-deploy-step fixture selection. `chooseFixtureFromRegistry` (introduced in #159 PR A) currently picks one fixture per `createDeployment` step. For multi-deploy, the planner needs to know:

   • Which deploy step's fixture supplies `mappingInstructions[].sourceElementId` (the SOURCE).
   • Which deploy step's fixture supplies a different `processDefinitionKey` for the migration target.
   • Both fixtures must declare `kind: 'bpmnProcess'` but be distinct files.

3. Per-consumer-site `providesValues` lookup. Today `bindModelDerivedFromFixture` reads the FIRST deploy step's `providesValues.ElementId[0]`. For migration, `sourceElementId` is unambiguously the source model's; `targetElementId` (where the planner wants a target model element id) needs to come from the target model's fixture.

Design sketch

This is a design-discussion issue rather than a small fix. Three sub-problems to settle:

Naming the deploy steps

The planner needs to discriminate "source deploy" from "target deploy" so downstream code knows which fixture's `providesValues` to consult. Options:

• Step-level tag: `RequestStep.role: 'source-model' | 'target-model' | …`. Hand-set by domain-semantics declarations that name the relationship.
• Fixture-level tag: `registry[i].role: 'source-model' | 'target-model'` so the planner picks a fixture by both `kind` AND `role`. Cleaner because the role is intrinsic to the fixture characteristic, not the step.

Declaring the dependency in domain-semantics

Some annotation needs to say "`migrateProcessInstance.mappingInstructions[].sourceElementId` reads ElementId from a SOURCE-role fixture, not the first one in the chain." Probably:

```jsonc
"operationRequirements": {
"migrateProcessInstance": {
"requires": ["ProcessDefinitionDeployed"],
"additionalDeployments": [
{ "role": "target-model", "kind": "bpmnProcess" }
],
"valueBindings": {
"request.mappingInstructions[].sourceElementId": "ElementId@source-model",
"request.mappingInstructions[].targetElementId": "ElementId@target-model"
}
}
}
```

The `@` suffix on the binding value tells `bindModelDerivedFromFixture` which deploy step's fixture to consult.

Two-or-more fixtures of the same kind

The fixture registry today has two `bpmnProcess` entries (`service-task.bpmn` and `simple.bpmn`). For migration scenarios both need to be present in the same chain. The selector needs to pick one for source and a DIFFERENT one for target.

Why this matters less than it looks

This work is real but the user-visible impact is narrow: only 2 of 7 ElementId gap entries depend on it. Both are migration endpoints — a niche-but-important Camunda feature. The other 5 are addressed by PR #163 (4 of them) and #165 (the 5th).

So a reasonable position is: defer until someone actually needs migration coverage; or use a synthetic `mappingInstructions` fixture (a JSON file pre-declaring the source/target element id pairs) as an interim measure. Document the limit.

Definition of done

• Migration endpoints emit a chain with at least two `createDeployment` steps deploying DIFFERENT bpmnProcess fixtures.
• `bindModelDerivedFromFixture` (or its successor) reads `providesValues.ElementId` from the role-appropriate fixture per consumer site.
• L3 invariants for both endpoints assert the chain shape AND the source/target value distinctness.

Out of scope

• Asserting that the migration actually succeeded (broker-level correctness — out of scope for the generator).
• Cases where the migration plan involves more than two models (uncommon; can be added later).

Start by reading chooseFixtureFromRegistry and bindModelDerivedFromFixture, then inspect the domain-semantics operationRequirements and existing L3 invariants for migrationProcessInstance and migrateProcessInstancesBatchOperation. Resolve how source and target deploy roles are represented and how additional deployments are declared. Done means both endpoints produce distinct source and target bpmnProcess deployments with role-specific ElementId bindings and assertions for chain shape and value distinctness.