arc-dind: agent logs are written under RUNNER_TEMP but the summary parser reads /tmp/gh-aw #72896

Split from #66926 (finding 1), as requested in #66926 (comment).

Summary

On the arc-dind topology awf writes the agent logs under ${RUNNER_TEMP}/gh-aw/sandbox/agent/logs, while parse_copilot_log.cjs reads /tmp/gh-aw/sandbox/agent/logs. The parser finds nothing and the agentic conversation is missing from every run summary.

State at v0.92.0

The firewall half of this was fixed by #66223, released in v0.91.4. We have taken that upgrade and deleted the firewall half of our workaround — confirmed, that one is closed.

The agent half is unchanged. @pelikhan's own recheck points at the same place: the summary parser consumes the unadjusted engine path in pkg/workflow/compiler_yaml_ai_execution.go (L195-L202 at ffdd9c9), while arc-dind execution rewrites the paths.

What we carry

steps:
  - name: Link the awf agent log dir the summary parser reads
    run: |
      mkdir -p /tmp/gh-aw/sandbox/agent "${RUNNER_TEMP}/gh-aw/sandbox/agent/logs"
      rm -rf /tmp/gh-aw/sandbox/agent/logs
      ln -s "${RUNNER_TEMP}/gh-aw/sandbox/agent/logs" /tmp/gh-aw/sandbox/agent/logs

post-steps:
  - name: Unlink the awf agent log dir before artifact consolidation
    # consolidation copies /tmp/gh-aw into RUNNER_TEMP/gh-aw and cannot replace a logs dir with the link
    if: always()
    run: rm -f /tmp/gh-aw/sandbox/agent/logs

The post-step is load-bearing: artifact consolidation copies /tmp/gh-aw into ${RUNNER_TEMP}/gh-aw and cannot replace a real logs directory with a symlink. So a naive symlink workaround trades a missing summary for a failing consolidation step — worth knowing for anyone else on arc-dind.

Ask

Give the agent log parser the same treatment #66223 gave the firewall parser, so producer, parser and artifact consolidation agree on one path. Acceptance for us is both summary panels populated and consolidation green with no symlink in the workflow.

Evidence

Run 37612927710, "no agent log files found in directory". That run has since been purged from our Actions history — our retention is far shorter than we assumed, which is also why several run ids in the umbrella issue now 404. We can reproduce on demand on v0.92.0.