fix: increase copilot-pr-merged-report timeout from 10 to 15 minutes

[Copilot]

The "Execute GitHub Copilot CLI" step was hitting the 10-minute timeout-minutes limit at exactly the wrong moment — the Copilot agent itself completed successfully (processed 50 PRs, created discussion), but awf container startup (~13s) + agent execution (~9m 44s) + container cleanup pushed the total step wall time just past 10 minutes, causing GitHub Actions to kill the step and mark the job as failure.

Evidence from the failed run:

• Step gh add: better tracking of added/modified files #34 started: 15:59:34Z, timed out: 16:09:34Z (exactly 600s)
• Agent process exited cleanly: exitCode=0, totalDuration=9m 44s
• Safe outputs confirmed success: discussion was created
• All 57 job steps succeeded exceptgh add: better tracking of added/modified files #34

Changes

• copilot-pr-merged-report.md: timeout-minutes 10 → 15; update success criterion text to match
• copilot-pr-merged-report.lock.yml: recompiled — step-level timeout-minutes updated to 15

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/github/gh-aw/actions/jobs/74449615662
  • Triggering command: /usr/bin/curl curl -s -H Authorization: ****** REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[github-actions]

Hey @copilot-swe-agent 👋 — great detective work tracking down the timeout race condition in the copilot-pr-merged-report workflow! The evidence trail (exact 600s wall-clock match, clean agent exit code, confirmed discussion creation) makes a compelling case for the 10→15 minute bump.

One thing worth addressing before merge:

• No tests present — the lock file regeneration touches ~99 workflows across the repo. Even a lightweight smoke-test or validation step (e.g. a CI job that compiles/lints the changed .md workflow source and verifies the emitted .lock.yml matches) would give reviewers confidence the bulk regeneration is correct and no lock file drifted unexpectedly.

If you would like a hand, you can assign this prompt to your coding agent:

Add a CI validation step for the workflow lock file compilation.
Specifically:
1. Check whether the repo already has a Makefile target or script (e.g. `make compile` or `scripts/compile-workflows.sh`) that regenerates `.lock.yml` files from `.md` sources.
2. If such a target exists, add or update a GitHub Actions CI workflow (e.g. `.github/workflows/ci.yml`) with a job that runs the compile step and then verifies there are no uncommitted changes to any `.lock.yml` file (using `git diff --exit-code`).
3. If no compile script exists, document in the PR body how the lock files were regenerated so reviewers can reproduce the output.

Generated by Contribution Check · ● 758.5K · ◷

[pelikhan]

@copilot merge main and recompile