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

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:

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.

Start with AGENTS.md and review the existing semantics, runtime-states, artifact-kinds, ElementId, and modelElementTypes introduced for #172 and PR #367. Compare the proposed local taxonomy and field-site affordance vocabulary against the listed request sites. Done means a reviewed design for the new ontology subtree and migration plan before implementation.