Add durable child invocation and continuation identity/auth contracts

[ChatGateAI]

Problem

Downstream runtimes need three related durable session contracts that are currently not exposed by Eve 0.27.12:

1. A child session.started event should carry canonical invocation lineage (child name, parent call/session/turn identifiers). emitTurnPreamble() currently emits only runtime identity.
2. Parking a task-mode runtime action or approval/input batch should preserve the originating event coordinates while advancing the persisted model-step identity used by the continuation. The current park path persists the same emission state.
3. A fresh parent transport authorization used to deliver a proxied input response should admit that continuation without replacing the child's durable execution authorization. The current descendant route forwards transport auth and the receiver assigns it wholesale to AuthKey.

These are one contract family: a resumed child turn must retain its durable identity/authorization while consuming a fresh, uniquely identified continuation admission.

Current source

• session preamble: packages/eve/src/harness/emission.ts lines 138–148
• runtime-action park: packages/eve/src/harness/tool-loop.ts lines 1969–1991
• descendant delivery: packages/eve/src/execution/workflow-steps.ts lines 555–575
• delivered auth assignment: packages/eve/src/execution/workflow-steps.ts lines 207–211

Desired contract

• Child invocation lineage is emitted canonically and missing child identity fails loud.
• The parked request retains its original event coordinates; the resumed model call uses the next persisted step identity and does not replay a turn preamble.
• Proxied input responses carry a one-shot continuation-admission identifier. Admission is validated against the fresh transport grant, then merged into—not substituted for—the child's durable execution auth. Missing, stale, or mismatched admission fails closed.
• Focused tests cover runtime-action results, approvals, input responses, cancellation, and durable workflow retry/replay.

Would the maintainers accept a focused contribution for this contract family? We can split the implementation into reviewable commits while keeping the behavior atomic at release.