Revert pr.yaml trigger to pull_request (unblock CI)

[Chris-Wolfgang]

Why

pull_request_target on main never fires — GitHub receives the PR events but the workflow never runs. This blocks required checks on every open PR, including Dependabot updates (#77, #78, #79) which can never merge.

What

• Revert trigger: pull_request_target → pull_request
• Remove ref: refs/pull/*/head and persist-credentials: false checkout overrides (only needed for pull_request_target)
• Keep fetch-depth: 0 on the gitleaks checkout
• Keep all other v3 improvements (gated stages, detect-projects, trusted config fetch, security scans)

Merging

This PR itself is subject to the broken required checks. To merge:

1. Either temporarily disable the ruleset in settings
2. Or use admin override to bypass required checks

Once merged, all existing open PRs should have their checks start running on the next push/rebase.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the repository’s PR validation workflow to run on pull_request instead of pull_request_target, aiming to restore required CI checks that are currently not firing.

Changes:

• Revert workflow trigger from pull_request_target to pull_request for PRs targeting main.
• Remove actions/checkout overrides that were specific to pull_request_target (PR ref checkout and persist-credentials: false).

[Copilot]

Removing the explicit ref: refs/pull/.../head changes actions/checkout to the default PR ref (typically the merge commit). If the intent is to keep validating the PR head commit (as before), set the checkout ref explicitly (e.g., to the PR head SHA). Also, removing persist-credentials: false causes the GITHUB_TOKEN credential to be written into the local git config by default; if you want to minimize token exposure to subsequent steps, consider restoring persist-credentials: false and updating any later git fetch operations to authenticate explicitly when needed.

[Copilot]

Switching the trigger to pull_request means the workflow definition is now sourced from the PR branch itself, so an untrusted PR can potentially modify this workflow to skip checks while still producing green check runs. If this repository needs to be hardened for external contributors, consider mitigating by running the validation workflow from the default branch (e.g., pull_request_target with tightly-scoped permissions and no secrets, or a reusable workflow invoked from a trusted workflow on main), and/or adding repo/ruleset protections for changes under .github/workflows/.

[Chris-Wolfgang]

Closing — found the actual bug: missing - name: line on the 'Install OpenSSL 1.1' step causes duplicate run: mapping key, silently preventing GitHub from parsing the workflow. Fixing that directly instead of changing the trigger.