Fix analytics-review pre-steps: survive Actions' bash -e; JIRA cloudId recovery via _edge/tenant_info

[amjithtitus09]

Follow-up to #152 covering three items found after its merge. Do not let the reviewer bot's own failure modes block this — the fixes below are what make it survive its own runs.

Item 1 (highest severity): the "never fails the job" JIRA step DID fail the job

Run 32017183079 (pull_request_target on #152) died ~15ms into "Fetch JIRA ticket context" with ##[error]Process completed with exit code 1.

Root cause: GitHub Actions invokes run: steps as bash -e {0} (visible in the log's shell: line), so errexit is inherited before our script's first line. set -uo pipefail does NOT clear an inherited -e — only an explicit set +e does. Combined with pipefail, this line killed the step on any branch without an ENG-nnn:

KEY=$(printf '%s' "$AW_HEAD_REF" | grep -oiE 'ENG-[0-9]+' | head -1 | tr '[:lower:]' '[:upper:]')

grep exits 1 on no match → pipefail propagates → errexit aborts → the no_ticket fallback on the very next line never runs. Every PR whose branch is not ENG-nnn hard-failed the reviewer (e.g. the #144 fix/consolidate-accounting-folder pattern).

Fix (belt and braces):

• Explicit set +e in the JIRA and lint steps, with a comment citing run 32017183079 so nobody "simplifies" it away.
• || true on the grep pipeline anyway.
• Audited all pre-steps: the "Resolve PR context" and skill-move steps keep set -euo pipefail deliberately (they must fail loudly); JIRA + lint must degrade gracefully.

Reproduced locally under bash -e (as Actions runs it) with AW_HEAD_REF=amjithtitus09-analytics-review-bot: main's version exits 1 before writing anything; this version exits 0 and writes the NO TICKET FOUND marker. (Earlier dry-runs of the extracted script passed only because they ran without -e.)

Item 2: JIRA cloudId recovery via /_edge/tenant_info (root cause confirmed)

Decisive evidence: against https://openhealthcarenetwork.atlassian.net, /rest/api/3/myself → 401 and /rest/api/3/issue/ENG-909 → 404 with real credentials AND anonymously — identical codes. The scoped API token is ignored entirely on the *.atlassian.net host, confirming Atlassian's two-URL rule: scoped tokens authenticate only against https://api.atlassian.com/ex/jira/{cloudId}.

The previous accessible-resources probe is unusable here: it returns 401 uniformly for no-auth, bogus-basic and bogus-bearer (verified three ways) — i.e. OAuth-Bearer-only, so its 401 says nothing about the credentials, the auto-recovery gated on its 200 could never fire, and its 401/403 arm would print a confidently-wrong "credentials rejected".

Fix: cloudId discovery now uses the public, unauthenticated GET <site>/_edge/tenant_info (live replacement for the retired _edgeAuth/tenantInfo):

GET https://openhealthcarenetwork.atlassian.net/_edge/tenant_info
→ {"cloudId":"5c16c56a-a2bc-478c-a952-c53290fa386f"}   [200]

If the issue fetch fails and the configured base is *.atlassian.net, the step fetches the cloudId and retries via https://api.atlassian.com/ex/jira/<cloudId> — so the workflow now works with either token type regardless of how the secret is set. .github/scripts/jira_sites.py is removed (no longer needed). All recovery/diagnosis arms tested against a local mock Atlassian server, under bash -e, all exit 0.

Admin action still recommended: set JIRA_BASE_URL to https://api.atlassian.com/ex/jira/5c16c56a-a2bc-478c-a952-c53290fa386f to skip the retry round-trip.

Item 3: hedged diagnostics (carried from orphaned c75b882)

Commit c75b882 was pushed ~2.5 min after #152's squash-merge and never reached main. Its hedging is carried forward here, now decisive where the evidence allows: when the configured host is *.atlassian.net, the marker recommends the ex/jira form outright (proven above); arms stay hedged only where JIRA's 404-for-unviewable behaviour makes "ticket missing" vs "not visible to this account" genuinely indistinguishable. No arm asserts credential failure — that evidence does not exist. Only HTTP codes, hostnames and cloudIds are ever printed; never secret values.

Also

• README: added the curl -s https://<site>.atlassian.net/_edge/tenant_info discovery command to the JIRA prerequisites.
• Recompiled with gh-aw v0.86.2: 0 errors, 0 warnings; lock contains set +e, tenant_info, and zero references to accessible-resources / jira_sites.py / myself.

Post-merge verification: gh workflow run analytics-review.lock.yml -f pr_number=146