copilot-setup-steps.yml builds gh-aw from source unnecessarily

[lpcox]

Problem

copilot-setup-steps.yml builds gh-aw from source (make deps-dev, make build, make recompile) and installs Go, Node.js, npm dependencies, etc. This is appropriate for workflows that modify gh-aw code, but workflows that only use gh-aw (e.g., token audit, optimizer) don't need any of that.

Importing copilot-setup-steps.yml into reporting/audit workflows causes:

• Unnecessary API calls — setup-go, setup-node, setup-uv all hit the GitHub API to resolve versions, contributing to rate limit exhaustion
• Slow setup — building from source adds minutes of setup time
• Rate limit failures — setup-uv calls the GitHub Releases API to find the latest version; when the installation token is already rate-limited, this step fails and blocks the entire workflow (see run #23984585463)

Current state

copilot-setup-steps.yml includes:

- curl install gh-aw extension
- actions/checkout
- setup-node + npm ci
- setup-go
- npm install
- make deps-dev
- make build          # builds gh-aw binary from source
- make recompile      # recompiles all workflow lock files
- setup-uv
- install gopls
- install typescript-language-server

Desired behavior

Workflows that only use gh-aw (not develop it) should be able to install just:

1. Copilot CLI — already handled by the AWF sandbox
2. gh-aw extension — gh extension install github/gh-aw

Without pulling in the full build toolchain.

Suggested approach

Either:

1. Remove copilot-setup-steps.yml import from reporting workflows and rely on their own steps: blocks (which already install gh-aw via extension)
2. Create a lightweight setup variant (e.g., copilot-setup-steps-lite.yml) that only installs the extension without building from source
3. Make copilot-setup-steps.yml conditional — skip build/recompile when the workflow doesn't need them

Affected workflows

• copilot-token-audit.md — daily audit, only needs gh-aw CLI + Python
• copilot-token-optimizer.md — daily optimizer, only needs gh-aw CLI

[lpcox]

@pelikhan

[lpcox]

Additional finding: gh aw logs --json discards partial results on rate limit

From the code analysis of pkg/cli/logs_orchestrator.go:

// Line 158-174 — iterates in batches
runs, totalFetched, err := listWorkflowRunsWithPagination(...)
if err != nil {
    return err  // ← All processedRuns from previous batches are discarded
}

When the rate limit hits during pagination, the function returns the error immediately, never reaching renderLogsJSON() at line 575. This means all 163 successfully downloaded runs in run #23986065459 were thrown away.

Suggested fix for gh aw logs

When --json is specified, DownloadWorkflowLogs should output whatever runs were successfully processed before the error, rather than discarding everything. Something like:

if err != nil {
    // If we have partial results and JSON output requested, output what we have
    if jsonOutput && len(processedRuns) > 0 {
        fmt.Fprintln(os.Stderr, console.FormatWarningMessage(
            fmt.Sprintf("Rate limit hit after %d runs, outputting partial results", len(processedRuns))))
        // ... build logsData from processedRuns and renderLogsJSON ...
    }
    return err
}

This would pair with the workflow-side fix (|| LOGS_EXIT=$?) to give the agent whatever data is available.