ci(warden): switch to analyze/report split workflow

[dcramer]

Splits the single getsentry/warden@v0 step into separate Analyze and Report steps using the mode input added in warden 0.38.0.

What changed:

• Analyze step runs with mode: analyze — no write token, uses GITHUB_TOKEN with pull-requests: read (added to permissions block) to read PR diffs
• App token is created after analyze, scoped to when a findings file was produced — keeping the high-privilege write token out of the analysis phase
• Report step runs with mode: report, receives the findings file and app token for write access; continue-on-error: true preserves original behavior
• Authenticate to Google Cloud now has an explicit if: always() && findings-file != '' guard so GCS upload still runs even when Report fails
• Findings rename/upload references steps.warden-analyze (same semantics, updated step id)

Requires: warden v0 tag pointing to 0.38.0+

---

View Session in Sentry

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f526307. Configure here.}

[sentry]

Bug: The app-token step lacks continue-on-error: true, causing the entire job to fail on transient errors instead of handling them gracefully.
_{Severity: MEDIUM}

Suggested Fix

Add continue-on-error: true to the app-token step. This will allow the job to continue and be marked as successful even if token creation fails, and the subsequent Report step will be correctly skipped due to its if condition.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/warden.yml#L46-L49

Potential issue: The `app-token` step in the GitHub workflow does not have
`continue-on-error: true`. If this step fails, for example due to a transient GitHub API
error, the entire job will be marked as failed. This is a regression from the previous
behavior where failures were handled gracefully. While subsequent steps are designed to
be skipped if `steps.app-token.outcome != 'success'`, the job's failure prevents this
graceful handling from working as intended. If this workflow is a required status check,
this could block pull request merges due to transient errors.