🐛 Detect explicit unsafe fork checkouts

[kyzzniko-lang]

What kind of change does this PR introduce?

Bug fix for the Dangerous-Workflow check.

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

A privileged pull_request_target workflow can explicitly check out an external contributor's fork without being reported when it uses this combination:

- uses: actions/checkout@v4
  with:
    repository: ${{ github.event.pull_request.head.repo.full_name }}
    ref: ${{ github.head_ref }}
    allow-unsafe-pr-checkout: true

The current check recognizes references containing github.event.pull_request or github.event.workflow_run, but not github.head_ref combined with an attacker-controlled fork repository.

What is the new behavior (if this is a feature change)?

Dangerous-Workflow reports the checkout when all three high-confidence indicators are present:

• the repository is selected from github.event.pull_request.head.repo.full_name;
• the ref uses github.head_ref; and
• checkout's allow-unsafe-pr-checkout input is explicitly true.

The narrow combination avoids reporting workflows that remain protected by checkout's safer default. Tests cover the unsafe combination, the protected default, a same-repository head_ref, and the existing pull-request expression behavior.

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

Towards #2404

Special notes for your reviewer

This is a draft pending maintainer feedback on the detection boundary. The focused tests pass locally on Go 1.25.6. The full checks/raw package has pre-existing Windows path-related failures in pinned-dependency tests; those failures do not touch the modified files.

Does this PR introduce a user-facing change?

Yes. Repositories with an explicitly unsafe fork checkout in a privileged workflow will receive a Dangerous-Workflow finding.

Dangerous-Workflow: detect explicit unsafe checkouts of pull request fork code in privileged workflows.