Remove GitHub auth from agent steps to mitigate prompt injection

[bholmesdev]

Summary

A maintainer adapting our example workflows for Vite identified that passing issues: write (or any write-scoped token) directly to the Oz Agent step exposes a prompt-injection attack surface: a malicious issue body or comment could instruct the agent to delete issues, remove comments, or abuse any permission granted by the token.

This PR hardens example workflows so the agent step never has access to GitHub credentials, and write operations are handled in post-processing action steps.

Changes

Across all 6 example workflows (examples/):

• Added persist-credentials: false to all actions/checkout steps so the GITHUB_TOKEN is not stored in the local git config where the agent could access it. This is needed because credentials are shared across the job, and need to be manually applied at each step to avoid splitting examples across multiple jobs (see Alternatives Considered).
• Removed GH_TOKEN / env from all warpdotdev/oz-agent-action steps. This does hurt the simplicity of our examples by blocking agent writes, so I'm open to discussion here.
• For workflows that push commits (respond-to-comment, auto-fix-issue, fix-failing-checks): added just-in-time git remote set-url with GH_TOKEN in the trusted commit-and-push step.
• Added prompt-level instructions telling the agent not to run gh commands or call the GitHub API directly.

Permission tightening:

• review-pr: removed unnecessary issues: write (only needs pull-requests: write).
• suggest-review-fixes: removed unnecessary issues: write.

Documentation:

• Added a security note to README.md explaining the tokenless-agent pattern.
• Updated setup text to reflect accurate permission requirements.

Alternative considered: separate jobs (Vite's approach)

Vite's PR solves this by splitting workflows into two jobs: a read-only job that runs the agent, and a write-capable job that consumes the agent's output via job outputs. Because jobs run on separate VMs, the write token never exists in the agent's environment.

We chose not to adopt this approach here because:

• Several of our examples (auto-fix-issue, respond-to-comment, fix-failing-checks) have the agent modify files that then get committed. Transferring a dirty working tree across jobs requires actions/upload-artifact / actions/download-artifact, adding complexity and latency that's inappropriate for example workflows meant to be simple and copy-pasteable.
• For our read-only analysis workflows (review-pr, suggest-review-fixes, daily-issue-summary), the two-job split would be strictly better and is worth considering as a follow-up.

Stripping credentials from the agent's environment within a single job is a middle ground here.

[captainsafia]

Should we update the "Checkout PR" step here to use the token to fetch as is the case with the other workflows?