fix: admit participant inject deliveries as temporal subjects

[Brad-Edwards]

Gap Claim

A valid DSL-142 participant-directed inject can bind a temporal constraint to its delivery declaration and compile to participant.behavior-specification.<spec>.inject-delivery.<binding>, but projecting that compiled time model to TimeModelDeclarationModel rejects the compiler-owned address as an unknown subject. This was found while qualifying APTL issue 601 against a real env-pack story with four participant deliveries. The parser, semantic validator, and compiler accept the scenario; planner admission fails before backend capability evaluation. RAES therefore cannot currently make its documented claim that a DSL-142 binding is an ordinary temporal subject.

Evidence paths:

• implementations/python/packages/raes_processor/compiler/time_model.py explicitly compiles delivery declaration refs to participant inject-delivery addresses.
• implementations/python/packages/raes_contracts/contracts/time_model.py admits only sdl.* or time-owned subjects.
• docs/decisions/issue-797-dsl-142-participant-inject-delivery-preflight.md states that the binding is an ordinary temporal subject.
• implementations/python/tests/test_dsl_142_participant_inject_delivery.py covers parse and compile but did not project the time contract.

Existing Surface Audit

Reviewed the DSL-142 authoring model and validator, declaration index and reference overlap, participant-delivery compiler, shared-time compiler and contracts, planner time admission, participant crossing/runtime contracts, SDL fixtures, public participant-control guide, issue 797 preflight, ADR-085, and reusable mixed-control amendments. The authored reference, compiled address, and time model already exist. No new SDL field, alias, schema, runtime carrier, or backend workaround is needed.

Lineage and Precedent

DSL-142 extends DSL-111 orchestration identity with participant addressee and delivery semantics. SEM-227 owns shared time. The issue 797 architecture explicitly composes these families by making the delivery binding an ordinary temporal subject. The compiler already implements that decision. This fix closes the contract projection mismatch at the existing ownership boundary.

Literature and Practice

No external semantic model is needed for this defect: it is internal referential integrity between two already governed RAES contracts. The relevant primary authorities are DSL-142, SEM-227, ADR-085, and the issue 797 preflight. The design retains their separation of orchestration occurrence, participant delivery, and temporal constraint rather than introducing a transport or scheduling model.

Alternatives

1. Do nothing or retain compile-only evidence: rejected because planner admission still prevents any conforming backend from realizing the authored scenario.
2. Rewrite the env-pack or patch APTL planning: rejected as a downstream force-fit that weakens or duplicates RAES semantics.
3. Accept every participant.* address as a temporal subject: rejected because it broadens the time contract beyond compiler-owned delivery declarations.
4. Admit the exact compiled participant inject-delivery address shape: selected.

Chosen Architecture

Extend TimeModelDeclarationModel reference validation to recognize only participant.behavior-specification.<id>.inject-delivery.<id> as an external declared-resource subject, alongside the existing sdl.* family. Keep the compiler, SDL, published schemas, and runtime delivery semantics unchanged. Add a DSL-142 regression that compiles the existing valid scenario and projects its time model through the portable contract.

Documentation Defense

Update the public participant-control guide to state that delivery temporal constraints compile under the participant address family and remain distinct from scheduling or proof of delivery. The existing issue 797 preflight remains the architectural source.

Verification Plan

• Run the targeted DSL-142 participant inject delivery tests.
• Run the targeted shared-time model tests.
• Run repository fast feedback only after staging, per policy.
• Link the code/test/doc artifacts to DSL-142 in Ground Control.
• Verify the APTL/env-pack qualification scenario reaches planner capability admission with the corrected RAES package.