Contributor fork PRs can appear red due to Actions approval and Vercel authorization

[dl-alexandre]

Hi, first off: thanks for building this. I spent some time trying to help with a few PRs and ran into what looks like a contributor-experience issue rather than a code issue.

On fork-based PRs, there seem to be two separate blockers that can leave otherwise valid contributions looking red or unstable:

1. GitHub Actions CI can end in action_required before any jobs actually start.
2. Vercel can fail with Authorization required to deploy.

I confirmed this while looking at fork-based follow-up PRs where the code was locally validated, but GitHub still showed the PR as unstable because the checks never reached a clean green state.

What I found:

• The repo workflow in .github/workflows/ci.yml does not manage Vercel directly.
• On fork PRs, the GitHub Actions run can be created but conclude as action_required without starting jobs.
• The Vercel status is posted externally and fails because the fork/integration is not authorized to deploy previews.

Why this matters:

• It makes outside contributions look broken even when the code changes are fine.
• It adds noise for maintainers trying to triage real failures.
• It raises the bar for casual contributors, since a red PR usually reads as a code problem.
• Smoothing this out would make it easier for people to contribute fixes confidently.

Possible directions:

• Make Vercel non-required or informational only for fork PRs.
• Adjust GitHub Actions fork PR approval behavior so trusted contributor PRs can run CI normally.
• Keep a required GitHub-native CI check, but avoid blocking merges on external preview deploy auth.
• If preview deploys from forks are intentionally restricted, document that clearly so contributors know a red Vercel check is not necessarily a code failure.

I’m happy to help further if useful, including testing workflow/settings changes from a fork and improving contributor-facing docs.