Fix analytics-review on workflow_dispatch: pass resolved PR context to the agent

[amjithtitus09]

Follow-up to #148/#151. Dry-run 32015295640 (workflow_dispatch, PR #146) went all-green — the v0.86.2 recompile fixed the ENOENT — but no review was posted. Two bugs, both fixed here.

Bug 1 (blocking): resolved PR context never reached the agent

The "Resolve PR context" pre-step worked (AW_PR_NUMBER: 146, AW_HEAD_REF: ENG-909 in every pre-step's env), but those are per-step env: vars — they don't exist inside the agent sandbox, and on workflow_dispatch the event payload has no PR either. The agent's own words from the run log:

This run was triggered via workflow_dispatch with no associated pull request (no PR/issue number in context, no GITHUB_HEAD_REF, event payload has no PR). There's nothing for the analytics-review lenses to review.

…and it called noop. So the manual/backfill dispatch path could never work.

Fix — use the proven file channel (the agent already reads /tmp/gh-aw/context/):

• The resolve step now writes /tmp/gh-aw/context/run-context.md (event name, PR number, head ref, head SHA — or an explicit NONE RESOLVED marker), and exposes proper step outputs (id: resolve_pr + $GITHUB_OUTPUT) for any future step-level consumers.
• The workflow prompt now instructs the agent to determine the PR under review from run-context.md, never from the event payload, treats a dispatch run with a resolved PR as a normal first-review/re-review, and reserves noop for runs where run-context.md genuinely says no PR.

(Interpolating ${{ steps.resolve_pr.outputs.* }} into the prompt was not possible: gh-aw renders the prompt in the activation job, while custom steps run later in the agent job — the file channel is the correct mechanism.)

Bug 2: JIRA 404 for ENG-909 — scoped-token root cause + self-diagnosing markers + auto-recovery

Root cause identified: JIRA_API_TOKEN is an Atlassian API token with scopes (read:issue-details:jira, read:issue-field-values:jira, read:comment:jira). Per Atlassian's docs, scoped tokens must target a different base URL than unscoped ones:

token type	required JIRA_BASE_URL form
unscoped	https://<site>.atlassian.net
scoped (what we have)	https://api.atlassian.com/ex/jira/<cloudId>

A scoped token sent to the *.atlassian.net form gets HTTP 404 — the same status JIRA uses for missing/unviewable issues — which fully explains the dry-run's HTTP 404 for ENG-909 with valid credentials.

Fixes in the JIRA pre-step:

• Auto-recovery: on a failed issue fetch, probe GET https://api.atlassian.com/oauth/token/accessible-resources (fixed absolute URL, independent of JIRA_BASE_URL; returns each reachable site's url + id=cloudId). If a cloudId can be resolved (configured URL matches a site, cloudId embedded in an ex/jira URL, or single-site token), retry via https://api.atlassian.com/ex/jira/<cloudId> — so either token type now works with either JIRA_BASE_URL form. Subsequent comment fetches use the recovered base.
• Self-diagnosing markers when it still fails, written into jira-ticket.md. All arms are worded as likely causes, never verdicts (a failed probe is not proof the credentials are bad — the endpoint may not accept basic auth for every token type), and report only HTTP codes, site URLs, cloudIds — never secret values:
  • probe 401/403 → inconclusive on its own; likely causes: JIRA_EMAIL doesn't match the token's account, or the token expired (scoped tokens expire ≤365 days).
  • probe 200, base matches no site → likely wrong base URL for the token type; lists the token's reachable sites + cloudIds and the exact value to set (https://api.atlassian.com/ex/jira/<cloudId>, no trailing slash, no /rest suffix).
  • probe 200, endpoint(s) correct → likely the token's account lacks access to the ENG project, or the ticket doesn't exist (JIRA 404s rather than 403s for unviewable issues).
  • probe unreachable/unexpected → explicitly inconclusive; enumerates the three real possibilities (wrong base URL for token type / no project access / nonexistent ticket).
  • Every inconclusive arm also surfaces the two-URL rule whenever the configured base host isn't api.atlassian.com (host shape only — the URL value is never printed).
• The earlier /rest/api/3/myself probe is removed: it isn't callable with these granular scopes and would have false-reported valid credentials as broken.
• Never-fail-the-job behaviour kept; JIRA secrets remain confined to this one pre-step.
• New helper .github/scripts/jira_sites.py (cloudId resolution + site summary; always exits 0). README updated with the base-URL form guidance.

Admin action (recommended)

Set JIRA_BASE_URL to https://api.atlassian.com/ex/jira/<cloudId> for the scoped token. The auto-recovery makes the current value work anyway (single-site tokens recover unconditionally), and if anything is still off, the marker in the run log / review context now says exactly what to change.

Verification

All pre-steps were already green in the dry-run; the agent demonstrably reads /tmp/gh-aw/context/ (it cat'd jira-ticket.md and lint-report.md in its tool log) — only the PR identity was missing, which run-context.md now supplies. The new JIRA logic was exercised locally against a mock Atlassian server using the step script extracted verbatim from the workflow: recovery path renders the full ticket; all failure branches write their marker and exit 0.

After merge:

gh workflow run analytics-review.lock.yml -f pr_number=146

Expected: the agent reads run-context.md, identifies PR #146, and posts a review; jira-ticket.md contains either the rendered ENG-909 ticket (via auto-recovery) or a precise likely-cause diagnosis instead of a bare 404.

Compiled with gh-aw v0.86.2, 0 warnings.