Gitleaks reports unrelated secret violations in pull requests

## Problem

Our team uses **Squash and merge** for merging pull requests into `master`, and we use `.gitleaksignore` to ignore expected secrets that have already been reviewed.

We've encountered an issue where `gitleaks-action` sometimes reports secret violations from **unrelated commits that are not part of the current PR's changes**. This happens when those commits originated from previous squash merges.

### Reproduction

The issue can be reproduced with the following workflow:

1. A developer creates `feature-1` from `master` and makes several commits.
2. While `feature-1` is in progress, another PR is **squash merged** into `master`. One of the squash commits contains an expected secret. Normally, we prevent merging PRs with Gitleaks findings, but since the commit introducing the secret has already been added to .gitleaksignore, the PR passes the check and is successfully merged into master.
3. Later, the developer creates `feature-main` from the latest `master` and makes several commits.
4. The developer merges `feature-1` into `feature-main` using a **normal merge commit**.
5. A PR is opened from `feature-main` to `master`.

At this point, `gitleaks-action` scans commits using:

```bash
git log -p -U0 --no-merges --first-parent baseRef^..headRef
```

Because the merge from `feature-1` is followed using `--first-parent`, the history includes the squash commits that already exist in `master`. Since squash commits are **not merge commits**, `--no-merges` does not exclude them.

As a result, `gitleaks-action` scans commits that are already present in the base branch and reports their secrets again, even though they are unrelated to the current PR. This also forces us to add those squash commit SHAs to `.gitleaksignore`, which should not be necessary.

## Expected behavior

For pull request scans, only commits that are **unique to the PR** should be scanned. Commits that already exist in the base branch (including previous squash merges) should be excluded.

One possible approach would be to obtain the commit list directly from the GitHub Pull Request API, for example:

```bash
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2026-03-10" \
/repos/{owner}/{repo}/pulls/{pull_number}/commits
```

This returns the commits that actually belong to the PR and avoids rescanning commits that already exist in the base branch.

Start at the pull-request scan path that runs `git log -p -U0 --no-merges --first-parent baseRef^..headRef` and compare its results with the commits returned by the GitHub Pull Request API. Done means the scan includes only commits belonging to the current PR and no longer reports secrets from unrelated commits already present in the base branch.

Written by the indexing model from the issue text.