Meta: encode test-meaningful behaviour for runtime entities — supersedes #150

Supersedes #150. The discussion in #150 evolved from a two-option choice (directlyExposedBy vs runtimeEntities) into a four-layer model and a four-class taxonomy of test-meaningful behaviour. This meta-issue tracks the resulting workstream; the original design discussion is preserved in #150's comments.

Background — what we converged on

The variant planner today emits tests that check little more than HTTP status. To emit meaningful tests it needs three things the OpenAPI spec does not encode:

1. Which runtime entity sits behind a semantic identifier (ElementInstanceKey, IncidentKey, JobKey, UserTaskKey).
2. Which lifecycle states the entity can be in, and which operations drive transitions.
3. Which model-level elements in a deployed artefact (BPMN file) are valid targets for a given operation, and what effect targeting them has on the running system.

These split into four layers (see #150 comments for the full derivation):

Layer 2 alone fixes only ~2 of the 12 ElementInstanceKey-consumer use-cases in #150's taxonomy (visualisation, audit). The other 10 (modification, variable scoping, user-task interaction, decisions, message correlation, jobs, ad-hoc, batch) need layer 0.

The four test classes

Independently, the discussion identified that test-meaningful behaviour breaks into four (pre-state, op, post-state, verifier) classes. Each gets its own child issue:

Class 2 (#189) is the layer-0 driver: encoding an entity's lifecycle and how ops drive it through that lifecycle is what unlocks modifyProcessInstance, cancelProcessInstance, resolveIncident, completeJob, completeUserTask, etc. Class 3 (#190) reuses Class 2's vocabulary for a downstream-entity verifier. Class 1 (#188) is largely already modelled. Class 4 (#191) is a polish layer.

Concrete work items

• #188 — Class 1: existence transitions (CRUD) — gap analysis
• #189 — Class 2: state-machine transitions on runtime entities — primary layer-0 driver
• #190 — Class 3: side-effect emission tests
• #191 — Class 4: aggregate-invariant tests
• Layer-2 ranking PR (directlyExposedBy or equivalent) — small fix to unblock #139 chain shape; non-foreclosing of layer 0
• Decide upstream-spec ask: should DeploymentProcessResult surface elementIds[] as provider:true? (See #150 comment "Tightened framing".)

Out of scope for this meta

• Any change to the provider:true semantics of existing leaves.
• A "manifest diff" style end-to-end snapshot guard (retired deliberately — see README).

Acceptance criteria for closing this meta

1. All four child issues either closed or explicitly marked won't-do with a recorded reason.
2. The two currently-skipped #37 invariants in configs/camunda-oca/regression-invariants.test.ts re-enabled and passing.
3. createProcessInstance.startInstructions[].elementId produces a meaningful chain (not the throwaway-process warm-up of #139).
4. At least one Class 2 test (e.g. modifyProcessInstance terminate) is generated end-to-end with an act+verify shape and runs green against the live broker.

cc/ #139 (the concrete planner regression that motivated #150).

Start with the four child issues (#188–#191) and the acceptance criteria for this meta-issue. Inspect configs/camunda-oca/regression-invariants.test.ts and the existing README context, then determine how the child work can re-enable the two skipped invariants and produce a meaningful createProcessInstance chain plus one end-to-end Class 2 test.