Orchestrate participant-control mechanisms and triggered effects at runtime

[Brad-Edwards]

Parent: #1068

Bounded outcome

Implement mechanism-neutral participant-control orchestration in the RAES
runtime so one or more conformant providers can resolve state and request
governed effects at exact participant/world crossings.

Replace the current implicit SEM-233 getattr resolver hook with the public,
versioned protocol adopted by #1068. Preserve the existing final-sink
commit-before-effect invariant.

Required runtime behavior

• Resolve the admitted apparatus/profile and exact provider set for the current
  participant, episode, crossing, state cut, policy revision, and history head.
• Invoke providers through the closed portable protocol without discovering or
  loading arbitrary executable code.
• Compose deterministic and advisory results under the adopted rules.
• Validate and durably commit the effective decision before backend effect or
  participant delivery.
• Translate requested effects only through existing governed RAES operations;
  injected or transformed content receives fresh identity, provenance,
  visibility, validation, and admission.
• Make trigger application idempotent and bound recursion, repeated firing,
  stale retries, and loops.
• Preserve append-only histories and safe bounded diagnostics for permit,
  abstain, deny, conflict, unsupported, failed, and applied results.

Acceptance criteria

• A real public provider protocol replaces undeclared duck typing.
• Runtime tests cover more than one mechanism and more than one profile without
  backend-name branches.
• IFC-resolved influence can trigger an inject and a non-inject typed effect.
• Permissive observation-only control, strict denial, transformation, advisory
  monitoring, and conflict cases are covered.
• Failed resolution, stale state, unsupported composition, failed commit, or
  denied effect causes no prohibited backend call or participant disclosure.
• Restart, replay, idempotency, concurrency, and both supported stores preserve
  the exact composition/effect history.

Non-goals

• Shipping a production IFC engine, monitor, policy product, model wrapper,
  gateway, or executable plugin registry in RAES.
• Protecting a backend or participant implementation from out-of-world
  interference.

Dependencies

• Blocked by Design modular participant control with extensible dynamic IFC and governed control effects #1068, Define extensible dynamic-IFC profiles and participant-control mechanism composition #1070, and Publish participant-control provider and profile contracts #1072.

Requirements

• RUN-320
• API-424
• RUN-319
• RUN-310
• API-404

These are OpenRAE/rae portable authorities. New SEM-235, API-424, RUN-320 and ASR-538 records and the ASR-536 amendment took authority through #1068 at merged revision ebb70a34b8e7d1cc8964c443841ae57e12ed1014; DRAFT does not mean implemented.

Architecture binding from #1068

Implement or consume ADR-108 and participant-control-composition/rev1 (PC-01–PC-15). Worked cases, requirement disposition, and the delivery graph supply the acceptance and dependency detail.

The linked design is accepted at merged revision ebb70a34b8e7d1cc8964c443841ae57e12ed1014. Dependent implementation must pin this accepted authority and the required released artifacts; listing a UID does not remove an implementation dependency.

Required predecessors within this program: OpenRAE/rae#1068, OpenRAE/rae#1070, OpenRAE/rae#1072.

Delivery PR: OpenRAE/rae#1234, merged into dev as ebb70a34b8e7d1cc8964c443841ae57e12ed1014.