bcr-pr-reviewer: check review freshness by commit_id, not commit timestamp (#2841)

`getPrApprovers()` decides whether a maintainer's existing approval
still applies to the PR's current content by comparing each review's
`submitted_at` against the head commit's date
(`latestCommit.commit.author.date`). A commit's author date is fully
controlled by whoever creates the commit (`GIT_AUTHOR_DATE` / `git
commit --date`) and GitHub preserves it on push, so the freshness cutoff
is attacker-controlled. By backdating a newly pushed head commit to a
time before an earlier approval, a stale approval of an earlier
innocuous commit keeps counting as valid for the new head the reviewer
never saw. `reviewPR()` feeds this `approvers` set directly into the
auto-approve + squash-merge decision, and since `CODEOWNERS` delegates
the whole `modules/` tree to this bot, the freshness check is the guard
that decides what merges into the registry.

This is the same freshness check hardened in #2764 (which stopped merge
commits from being excluded from the cutoff) and complements #2653
(which pinned the merge to the analyzed head SHA); both kept the
timestamp comparison, which is what this change removes.

The fix compares each review's `commit_id` against the current PR head
SHA instead of comparing timestamps. A review only vouches for the exact
commit it was submitted against, so it is fresh iff its `commit_id`
equals the head. This is timestamp-free and also handles the
merge-commit case without special-casing parent counts.

`index.test.js` is updated to `commit_id` fixtures and adds a regression
test for the backdated-head-commit case; it keeps the checks that a
genuinely head-matching approval still counts and that a later
non-approving review overrides an earlier approval. `node --test`
passes.