Fix four failing workflows: traffic, message center, catalog, PR sweeper

[soyalejolopez]

Four workflows have been failing independently. Each had a distinct root cause.

Collect Traffic Data — 100% failure daily since ~7/6

The token is expired, but the run gave zero diagnostic to say so. Two bugs hid it:
gh api stderr went to /dev/null, and ::error:: was echoed to stdout from
inside a $(...) substitution, so the error text got captured into a variable
instead of reaching the log. Both fixed, plus an upfront empty-token guard.

Requires a rotated TRAFFIC_TOKEN to actually go green. The traffic API needs
push access on this repo; GITHUB_TOKEN cannot read traffic at all.

Update Message Center — weekly failure since 7/6

The branch push succeeds every time; only gh pr create fails, with
"GitHub Actions is not permitted to create or approve pull requests". That's an
org policy, not a bug in the run, and it shouldn't throw away a branch that
already landed. Now warns, writes a job summary with a compare URL, and exits 0.
Any other create failure still fails hard.

Also seeds the remote-tracking ref so --force-with-lease stops dying with
"stale info" on same-day reruns.

Build catalog — 5 of 10 recent runs

GH006: Protected branch update failed for refs/heads/master. The publish job
pushed generated files straight to master. Runs that appeared to pass only did so
through the "no changes" early exit, so the catalog has silently not been landing.

Now escalates: direct push, then rebase and retry, then a catalog-refresh/*
branch with a PR and auto-merge. No retrigger loop — all four generated files sit
outside this workflow's paths: filters.

PR Sweeper Report — 3 failures on 7/22

Fork PRs leave workflow_run.pull_requests[0].number empty, so the job falls back
to a SHA lookup that ran exactly once. PR #495 was created at 16:49:09Z and queried
at 16:49:37Z — 28 seconds, before GitHub's commit-to-PR index had propagated. The
same SHA resolves fine now.

Retries at 0/3/8/15s. If it still can't resolve it warns, still posts the commit
status, and returns instead of exiting 1. No security change: setStatus only
needs the trusted head SHA and the deterministic guardrails remain the
authoritative merge gate. Only the sticky comment is lost, and a red X on a healthy
PR is worse than a missing comment.

---

Validated offline: YAML parse, bash -n on every run block, and stub harnesses
covering expired token, policy block, protected branch, failed auto-merge, and
same-day rerun.

Both PR-creating workflows now honor an optional AUTOMATION_PAT secret, which
bypasses the Actions PR restriction. They degrade gracefully without it, so this
is safe to merge before any secret or settings change lands.

[github-actions]

🛰️ PR Sweeper report

Risk: 🟠 MEDIUM · Security gate: ✅ passing · Files: 4

🔒 Automated guardrails (authoritative)

	Category	Location	Finding
⚠️	scope	—	Touches security-sensitive path(s): .github/scripts/pr-sweeper/report.mjs, .github/workflows/build-catalog.yml, .github/workflows/traffic-stats.yml, .github/workflows/update-message-center.yml. Maintainer + security review required.

🤖 Dual-model AI review (advisory)

AI review unavailable for this run (models not reachable or no diff). Guardrails above are unaffected.

• GPT-class reviewer (openai/gpt-5): skipped — GitHub Models HTTP 413: {"error":{"code":"tokens_limit_reached","message":"Request body too large for gpt-5 model. Max size: 4000 tokens.","details":"Request body too large for gpt-5 model. Max size: 4000 tokens."}}
• Deep-reasoning reviewer (openai/o3): skipped — GitHub Models HTTP 413: {"error":{"code":"tokens_limit_reached","message":"Request body too large for o3 model. Max size: 4000 tokens.","details":"Request body too large for o3 model. Max size: 4000 tokens."}}

---

The automated guardrails are authoritative and gate the security status. The AI review is advisory and never auto-merges. Thanks for contributing to FastTrack! 🛩️