Ontology: per-field-site affordance layer for model-element selection

[jwulf]

Context

Follow-up from #172 (PR #367). That fix made createProcessInstance.startInstructions[].elementId
resolve to a real, broker-accepted model element by adding:

• providesElements: {id,type}[] on deployment fixtures (the model's typed-element ABox), and
• modelElementTypes on the ElementId semantic type (acceptable element types, in
  preference order, excluding startEvent).

This is correct and decoupled (no BPMN vocabulary in planner code), and it works. But it places a
per-field-site constraint onto the semantic type, which is conceptually the wrong layer.

The abstraction gap

ElementId is a single semantic shared across many request sites, each with different
acceptable-element rules:

Site	Acceptable elements
createProcessInstance.startInstructions[].elementId	any flow node except start event
runtimeInstructions[].afterElementId	flow nodes incl. end event
modifyProcessInstance.activateInstructions[].elementId	activatable elements
…terminateInstructions[].elementInstanceKey	active element instances (runtime, not model)
migration mappingInstructions source/target	mappable elements
element filters	any referenced element

Putting modelElementTypes on the ElementId semantic flattens a per-site predicate onto the
type. It's harmless today because only createProcessInstance uses the literal model-derived
fallback (all other sites use runtime emission: __PENDING__ + step-extract), but it won't
generalise: the moment a second site needs a literal model element with a different rule, the
single modelElementTypes list is wrong for one of them.

Proposed direction

Introduce a middle ontology layer — affordance — between semantics (field meaning) and
runtime-states (server state machine):

(model-element kind) x (request-field role/site) -> selection predicate + expected runtime-state effect

Concretely:

• A small local element-type taxonomy (subsumption: serviceTask is-a task is-a activity
  is-a flowNode; startEvent is-a event is-a flowNode; ...) so rules can be expressed as
  flowNode \ startEvent rather than enumerating every concrete type.
• A field-site affordance vocabulary keyed by request field-role (not by semantic type), each
  binding a selection predicate over the taxonomy plus the expected runtime-state effect for the
  test expectation.
• Migrate modelElementTypes off the ElementId semantic and onto the per-site affordance.

sBPMN assessment

sBPMN 2.0 was evaluated as the element-type TBox. It would give us
the subsumption hierarchy for free, but it's heavyweight, BPMN-specific external OWL, and the repo
already has its own ontology idiom (semantics / runtime-states / artifact-kinds). Recommendation:
a lightweight local taxonomy over importing sBPMN wholesale. sBPMN can inform the taxonomy's
shape.

Notes

• providesElements on fixtures is the right ABox either way — no change needed there.
• This is an "ask first" new ontology sub-tree per AGENTS.md; design review before implementation.

Spun off from #172.

[jwulf]

Concrete motivating case from the 404 fake-ID emitter (#381 / #382): the emitter is currently scoped to GET (read-by-key) endpoints because those have unambiguous "resource not found" → 404 semantics. Live-broker validation showed that mutating/command endpoints do not — a fake key on job completion, incident resolution, process-instance cancellation, or user-task actions yields a broker 503 (command rejection) or 400, not a 404.

This is precisely a per-field-site affordance: the path-id's role (lookup target vs command target) determines the expected not-found behaviour, and it's not derivable from the OpenAPI spec alone. Once this layer lands, the 404 emitter can safely re-admit the non-GET endpoints whose path id is a pure lookup target.