Propagate GH_AW_INFO_ENGINE_ID into setup steps so setup OTel spans emit gh-aw.engine.id

[Copilot]

Bug Fix

gh-aw.<job>.setup spans were missing gh-aw.engine.id because setup runs before aw_info.json exists and setup steps did not receive GH_AW_INFO_ENGINE_ID. This blocked engine-segmented setup observability (e.g., p95 setup latency and pre-agent failure rate by engine).

What was the bug?

• Setup span emission (sendJobSetupSpan) already supports GH_AW_INFO_ENGINE_ID, but compiled setup steps did not inject that env var.
• Result: setup spans were unlabeled by engine, while later spans had engine context.

How did you fix it?

• Setup-step engine env propagation

  • Added getEngineIDForSetup(data *WorkflowData) to resolve engine ID from:
    • EngineConfig.ID (preferred)
    • legacy AI field (fallback)
  • Injected GH_AW_INFO_ENGINE_ID into generated Setup Scripts step env in:
    • action mode (uses: ./actions/setup)
    • script mode (bash .../setup.sh)

• Compiler/output alignment

  • Updated setup-step generation to include engine ID only when non-empty.
  • Updated affected wasm compile goldens to reflect setup env output changes.

• Focused coverage

  • Added setup-step tests for engine ID injection in both action and script modes.

- name: Setup Scripts
  env:
    GH_AW_SETUP_WORKFLOW_NAME: "..."
    GH_AW_CURRENT_WORKFLOW_REF: ${{ github.repository }}/.github/workflows/....lock.yml@${{ github.ref }}
    GH_AW_INFO_ENGINE_ID: "copilot"

Testing

• Added targeted compiler tests asserting GH_AW_INFO_ENGINE_ID is emitted in setup steps (action + script modes), and refreshed corresponding wasm golden outputs.