Let a fork's records survive their own squash (#723)

[MongLong0214]

Closes #723.

preserve ran on pull_request, which hands a fork's workflow a read-only token. The job read the branch's commits, built the inherited note correctly, and could not publish it:

merge-type=squash  records=4  pushed=false
→ the record was attached on the runner and is about to be discarded with it

That is what happened to #720 — four records lost at the merge, recovered by hand afterwards, in the repository whose whole claim is that records survive a squash. contents: write was already declared; it cannot grant what the event does not carry.

Why pull_request_target is safe here

That event is better known for handing an attacker a write token, and the mechanism is specific: it checks out the base by default, and the hole opens when a workflow points the checkout at the fork's head and then runs it.

This job never has. It checks out base.ref — for an unrelated reason, because refs/pull/<n>/merge is gone once the PR closes — installs and builds from that tree, and brings the fork's commits in as refs/commitlore/pr-head, read for trailer blocks and nothing else. Data, never scripts.

The change is one line. What makes it safe was already true.

Being already true is not staying true

So the two rules are asserted rather than requested. test/preserve-workflow-safety.test.ts reads the workflow with comment lines stripped — a comment cannot satisfy it — and requires that the checkout names the base branch and that every command mentioning the fork ref is a git fetch.

mutation	fails
revert the trigger to pull_request	the trigger case
ref: github.event.pull_request.head.sha	the base-branch case
git checkout refs/commitlore/pr-head -- . && npm ci	three, incl. every mention is a fetch

What this does not do

It runs on close, so it publishes rather than gates: a merge that cannot carry its records still happens first, and the report is the only thing standing there. Making preserve a required check cannot fix that — the close event is after the merge by construction.

[github-actions]

CommitLore — record lint

Trailers: clean — 3 commits in origin/main..9d1d7b551e4791c835855d677fc7070b7a683948
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 3 paths; query one path at a time to follow its rename chain (3 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}