Support matrix-aware concurrency groups for agent jobs

## 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:

```yaml
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:

```yaml
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:

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

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

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