Converter scrambles an existing diagram's layout on re-convert (random placement + forced auto-layout)
## Problem
When a model is opened in BPMN.io but the model's recorded modeler differs from `bpmn_io` (for example a second, form-based `modeler_api` modeler recorded itself as the model's `modeler_id` on its last save), `modeler_api` takes the **convert** path instead of loading the stored diagram. The converter then:
1. places every shape at a **random** position -- `js/bpmn_io.convert.js`: `modeling.createShape(el, {x: Math.floor(Math.random() * 400) + 1, y: ...})`, and
2. runs a full **auto-layout** afterwards (`Drupal.bpmn_io.autoLayout()` -> `layoutProcess()`), discarding any positions.
So every time such a model is opened, its diagram layout (node positions and flow waypoints) is **scrambled**, even though the stored diagram with the real coordinates is still present and untouched. Only the executable structure survives; the visual layout is lost.
## Who hits this
Any model owner that exposes **more than one** editing modeler, so a model's `modeler_id` can differ from `bpmn_io`. Concretely, the Orchestra workflow engine ships a form-based "classic" modeler alongside BPMN.io; saving in the form modeler forces a re-convert (and scramble) on the next BPMN.io open. ECA is unaffected today because it uses a single modeler.
## Proposed fix
Re-use the layout from the stored diagram during convert:
- `BpmnIo::convert()` extracts shape bounds (keyed by element id) and edge waypoints (keyed by `sourceRef>targetRef`, since the flow id is regenerated on convert) from the stored model data and passes them to the converter via `drupalSettings`.
- The converter JS places each shape at its stored bounds (falling back to placeholder placement only for elements with **no** stored layout, i.e. genuinely new ones) and applies stored waypoints to the recreated connections.
- `autoLayout()` gains a flag to **skip** the re-layout when a stored layout was applied, so the restored positions are kept. Brand-new models (no stored diagram) auto-lay-out exactly as before.
Structure and configuration still come from the owner's components, so the model stays authoritative while the existing layout is preserved.
## Merge request
A merge request implementing this is available: \!167
issue