feat(runner): delegate whole workflow to session-capable environment via exec_session (REQ-052)

[Shooksie]

Summary

Make a workflow whose environment is a session-capable plugin delegate the whole workflow to that environment's own animus via a single EnvironmentClient::exec_session (REQ-052), instead of running phases locally or routing them per-phase.

Product intent: "The node is a FULL animus that runs the whole workflow standalone and streams. From our perspective it should be just ONE workflow (coding) that has environment = animus-environment-railway."

When the resolved environment advertises environment/exec_session, the runner prepares a bare node, calls exec_session(subject_id, workflow_ref, dispatch_input, on_journal) once, forwards each streamed environment/journal event home through its WorkflowEventEmitter, tears the node down, and drives the run to terminal from the session's terminal ExecSessionResponse. It executes no phase itself and prepares no per-phase held node.

Investigation (answers to the design questions)

1. How does the runner currently handle a workflow with environment set?

(a) per-phase routing — not local, not nothing. This is REQUIREMENT-048, already on main. execute_workflow_with_hub (src/workflow_execute.rs) resolves the environment once per run just before the phase loop:

• src/workflow_execute.rs ~L350: BrokeredEnvironment::acquire_from_env(...) (daemon owns one node per run over a private socket) takes precedence; else
• ~L358–384: PreparedEnvironment::prepare_off_runtime(...) (runner owns one bare node) via phase_environment::resolve_workflow_environment(...);
• ~L387–392: the chosen node becomes held_environment: &dyn HeldEnvironment, threaded into every run_workflow_phase(PhaseRunParams { held_environment, .. }) call (~L458, ~L687).

Each phase's harness command is then run inside that held node via HeldEnvironment::exec_session → EnvironmentClient::exec_stream (src/phase_environment.rs L408–423, L891). Note the name collision: the existing HeldEnvironment::exec_session is a per-phase harness exec, not the REQ-052 whole-workflow EnvironmentClient::exec_session this PR adds. In REQ-048 the home runner still drives the phase loop; the node is a shared workspace/sandbox, not a standalone animus.

2. Where is the branch point, and was exec_session already wired?

Branch point: in execute_workflow_with_hub, immediately before the REQ-048 resolution block (right after workflow_ref is resolved). Inserted at src/workflow_execute.rs L326–367 — if the resolved environment is session-capable, delegate and return; otherwise fall through to the unchanged REQ-048 per-phase path.

The REQ-052 EnvironmentClient::exec_session + forward_journal + EnvironmentJournalEvent are defined but not called by the runner anywhere — and, importantly, not reachable from the runner's current pins:

• The runner pins orchestrator-core to rev d03cd174 (Cargo.toml L46). REQ-052 exec_session landed in bcce5012 ("orchestrator-core: EnvironmentClient::exec_session + journal forwarding (REQ-052)"), which is one commit past d03cd174 on the unmerged branch agent/v0.7.0/env-exec-session (not on origin/main).
• That commit's own message notes it "Needs animus-environment-protocol with exec_session (local [patch] used to build; NOT committed)" — and indeed no published animus-environment-protocol tag (incl. the pinned v0.7.0-rc.6) defines ExecSessionRequest/Response, METHOD_ENVIRONMENT_EXEC_SESSION, or NOTIFICATION_ENVIRONMENT_JOURNAL.

So this PR wires the runner side against the REQ-052 API (exact signatures/types taken from bcce5012), and the actual call is compiled under a feature until those two pins are advanced (see Build gating).

3. How does the runner detect a "session-capable" environment?

Via the plugin manifest capability list. PluginManifest.capabilities: Vec<String> is documented as "Methods implemented by the plugin." A session-capable environment advertises "environment/exec_session" there. environment_is_session_capable (src/workflow_session.rs) discovers environment plugins with orchestrator_plugin_host::discover_by_kind(project_root, "environment"), selects by exact name (else the sole installed one — mirroring EnvironmentClient::resolve), and checks capabilities_advertise_exec_session(&manifest.capabilities). Any discovery error / missing plugin fails safe to false (keeps the per-phase path).

Change

• New src/workflow_session.rs (REQ-052 remote-animus session):
  • capabilities_advertise_exec_session / environment_is_session_capable — detection.
  • map_journal_event_kind — node journal kind → coarse RuntimeWorkflowEventKind (phase lifecycle only; the single terminal event is emitted by the driver so it isn't double-emitted).
  • session_status_to_workflow_status — terminal ExecSessionResponse.status → WorkflowStatus (fails closed to Failed on unknown).
  • delegate_workflow_via_session — prepare bare node (repo on metadata.github_repo), exec_session with a Send + Sync journal-forwarding closure, best-effort teardown, synthesize WorkflowExecuteInternalResult. Blocking EnvironmentClient work runs on a dedicated multi-thread runtime so the resident-host I/O driver outlives prepare → exec_session → teardown (same hazard PreparedEnvironment::prepare_off_runtime guards).
  • Unit tests for all pure logic (detection, journal mapping, status mapping, spec shaping).
• src/workflow_execute.rs — the delegation branch (full runs only; --phase runs keep the per-phase path).
• src/lib.rs — register pub mod workflow_session;.
• Cargo.toml — add the remote-animus-session feature.

Build gating — remote-animus-session (default OFF)

Because REQ-052 exec_session / EnvironmentJournalEvent (orchestrator-core, past the pinned rev) and the environment/exec_session protocol types (env-protocol, past the pinned tag) are not in the current pins, the delegation call is behind the remote-animus-session cargo feature:

• feature OFF (default): environment_is_session_capable returns false, so the branch never delegates and behavior is unchanged. The pure detection/mapping logic still compiles and is unit-tested.
• feature ON (node/CI): builds against a REQ-052 orchestrator-core rev + an animus-environment-protocol tag that ship exec_session.

To land end-to-end, three pins must advance together (a coordinated protocol release, outside this repo):

1. animus-environment-protocol — publish ExecSessionRequest/Response, METHOD_ENVIRONMENT_EXEC_SESSION, NOTIFICATION_ENVIRONMENT_JOURNAL under a tag.
2. orchestrator-core — merge bcce5012 (REQ-052) repinned to that env-protocol tag; cut a rev.
3. this runner — repin orchestrator-core/siblings to that rev + animus-environment-protocol to that tag, and build --features remote-animus-session.

Testing

needs node/CI build+test — not built locally per policy (ao-cli builds/tests run on ephemeral nodes/CI). Unit tests added for the pure logic; the exec_session round-trip needs the feature + advanced pins.

[Shooksie]

Added commit for TASK-722 (in-node agent transcript relay), bumping v0.4.47 → v0.4.48.

on_journal now mirrors the node's agent-run transcript (output_chunk/tool_call/...) into the parent run dir — before the lifecycle map — re-keying the node run id onto the parent workflow id so the portal's /api/workflows/<id>/logs (matched by wf-<workflow_id>- prefix) groups it under the parent run. Fixes remote runs showing "No output captured for this run". Lifecycle stays journal-only (no double-journaling).

Paired with the node-side relay in animus-env-transport PR #2 (streams journal/event frames the parent consumes). cargo check green with and without --features remote-animus-session; 3 new unit tests + 225 existing pass.