Support matrix-aware concurrency groups for agent jobs

[susmahad]

Problem

When a reusable gh-aw workflow is called from a matrix strategy, the compiled agent job's concurrency group (gh-aw-copilot-${{ github.workflow }}) serializes all matrix entries. This prevents parallel execution of independent agent runs.

Example

A driver workflow fans out multiple findings via a matrix:

pipeline:
  strategy:
    matrix:
      finding: ${{ fromJSON(needs.route.outputs.findings) }}
    fail-fast: false
  uses: org/repo/.github/workflows/my-pipeline.lock.yml@main
  with:
    issue_number: ${{ matrix.finding.issue_number }}

Each matrix entry is an independent finding with its own branch and PR. They have no shared state and should run concurrently. However, the compiled .lock.yml contains:

concurrency:
  group: "gh-aw-copilot-${{ github.workflow }}"

Since github.workflow is the same for all matrix entries within a single workflow run, the second agent job waits for the first to finish, the third waits for the second, and so on.

Observed behavior

Jobs queue sequentially — pipeline (10, issue-1) / pre_activation shows:

Waiting: This job is waiting on pipeline (10, issue-6) / activation to complete before running.

Expected behavior

Each matrix entry should run its agent job concurrently, since they operate on independent data (different issues, different branches, different PRs).

Proposed solution

Make the agent job's concurrency group matrix-aware. When the compiled workflow detects it is being called within a matrix strategy, include a matrix-discriminating key in the concurrency group. For example:

concurrency:
  group: "gh-aw-copilot-${{ github.workflow }}-${{ github.job }}-${{ strategy.job-index }}"

Or allow the workflow author to opt in via a frontmatter field:

concurrency:
  group: skynet-finding-${{ inputs.issue_number || inputs.finding_locator || github.run_id }}
  agent-concurrency: per-matrix-entry