fix(workflows): resolve PR number from aw_context in /review reviewers

[jamesadevine]

Summary

/review was routing correctly — all five reviewers dispatched on #1670. The bug was downstream: they ran, reported success, and reviewed nothing.

Under slash_command.strategy: centralized, the generated agentic_commands.yml router dispatches each reviewer via workflow_dispatch, so the payload carries neither github.event.pull_request.number nor github.event.issue.number. The PR identity arrives only in the aw_context input as {item_type: "pull_request", item_number: "<N>"}.

In shared/pr-diff-data-fetch.md that meant:

• PR_NUMBER resolved empty → the step wrote empty pre-fetch files and exited 0. The agent then posted a successful run: "No review performed: pre-fetched PR data files were empty".
• The cache key collapsed to the constant pr-prefetch-, so all five reviewers restored the same poisoned 349-byte entry.

Evidence from run 30698000006 (and the four sibling runs):

key: pr-prefetch-
Cache restored from key: pr-prefetch-
  PR_NUMBER:
No PR number in the event payload; writing empty pre-fetch files.

Changes

• PR_NUMBER gains an aw_context fallback, guarded by item_type == 'pull_request' as required by gh-aw ADR-31820 — item_number is shared across entity kinds, so an issue-routed run must not leak its number into the PR slot.
• Cache keys re-scoped to pr-prefetch-<pr-number>-<sha> so the restore-keys prefix still matches when a dispatch run knows the PR number but not the head SHA. pr-data-head-sha.txt continues to reject stale entries, which is what makes a prefix-matched restore safe.
• Fail loudly on an unresolved PR number instead of writing empty files and exiting 0. Every consumer of this component is a PR reviewer, so a missing PR number is always a bug — and the fail-open behaviour is precisely what hid this.
• Reviewer bodies defer to the builtin <github-context> block. gh-aw already injects pull-request-number with the aw_context fallback baked in, so hand-rolling the expression was redundant.

Note on github.aw.context.*

Worth recording, since it shaped the fix: github.aw.context.item_number is a prompt-only virtual namespace. Verified by compiling all three variants:

Usage	Result
Step env:	Passes through untransformed → silently empty at runtime
Markdown body	Fails compilation: 3 unauthorized expressions found
Compiler-internal <github-context>	Resolves to GH_AW_EXPR_463A214A with the full fallback

Hence the raw fromJSON(...) form in step env:, and deferring to the builtin block in the body.

Test plan

• gh aw compile — 27 workflows, 0 errors; the 4 warnings are pre-existing and in unrelated workflows (bash-lint-auditor, clippy-fixer, test-reducer, frontmatter-aligner).
• gh aw validate — all five reviewers pass.
• Verified the compiled lock files resolve as intended in all five:

  PR_NUMBER: ${{ github.event.issue.number || github.event.pull_request.number || (fromJSON(github.event.inputs.aw_context || '{}').item_type == 'pull_request' && fromJSON(github.event.inputs.aw_context || '{}').item_number) || '' }}
  key: pr-prefetch-${{ github.event.pull_request.number || fromJSON(github.event.inputs.aw_context || '{}').item_number }}-${{ github.event.pull_request.head.sha || github.run_id }}

• Confirmed agentic_commands.yml is unchanged — routing was never the problem.
• Confirmed the builtin pull-request-number still reaches the prompt (GH_AW_EXPR_463A214A).

Still needs a live check: comment /review on this PR once merged (or on a scratch PR) to confirm the reviewers pick up a real diff end to end. The empty-diff path now hard-fails, so a regression will be loud rather than silent.

[azure-pipelines]

Azure Pipelines:
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.