chore(release): restore the 6.5.2 version record lost to a squash

[John-David Dalton (jdalton)]

Version 6.5.2 has been on npm since 2026-07-31, but this repository still says it is on 6.5.1. This PR makes the repository agree with what was actually published.

The reason for the gap is that the commit which bumped the version was collapsed by a squash. Once that commit was gone, nothing in the repository stated the version 6.5.2 anywhere, so the scheduled release-reconcile job had no bump commit to derive a tag from. It failed on every run for days, which is exactly the outcome it exists to prevent.

How the gap was diagnosed — the timeline brackets the publish on both sides

The release-reconcile job said plainly what was wrong: "no reachable commit whose version-source manifest reads 6.5.2 while its parent does not", and it deliberately refused to pick a commit itself, noting that "the healer never guesses a commit to tag". That refusal was correct — this needed a human decision.

The commit was identified from timing rather than content, because the usual signals were unavailable: npm recorded no gitHead, and the changelog had not changed since 6.5.1 so it could not distinguish between candidates.

Time (UTC)	Event
04:07	2fb463c0 committed — the last commit before the publish
04:21–04:23	the npm-publish workflow ran and failed
04:57	6.5.2 appeared on npm
05:40	073e3fb3 committed, described as pointing the self-pin at "the published 6.5.2"

The commit 93 minutes after the publish already refers to 6.5.2 as published, which brackets 2fb463c0 as the content it was built from.

What this changes, and what it deliberately does not

Changed. The version in package.json becomes 6.5.2, and the 6.5.2 changelog section is added. Both are copied from the published npm artifact rather than regenerated, so the repository records what consumers actually installed instead of a plausible reconstruction of it.

Not changed. The v6.5.2 tag already points at 2fb463c0 and stays there. Tags are immutable under the fleet-tag-protection ruleset, and that is the right posture — moving a published tag so it pointed at different content than consumers fetched would be worse than the inconsistency it fixed. The tag alone was enough to turn release-reconcile green.

Ran / did not run

Ran. The reconcile job was triggered by hand after the tag landed and returned success, its first green run after a full day of hourly failures.

Did not run. The package was not rebuilt or republished. 6.5.2 on npm is untouched; this only corrects the repository's record of it.

The rule worth drawing from this

A squash must not collapse across a release boundary. A release needs a commit that states its own version, because that commit is the only link between a published artifact and the source it came from. When it is squashed away, the artifact still exists but its provenance does not, and no automation can recover it without guessing.

Worth noting the squash tooling already has a publishedReleaseBlocksSquash guard, so it is worth understanding why that did not prevent this before relying on it next time.

[John-David Dalton (jdalton)]

Closing as obsolete — everything this PR set out to do has since landed independently.

The PR restored the 6.5.2 version record by setting version: 6.5.2 and dropping the provenance-baseline entry that marked the release as un-taggable. Since then:

• v6.5.2 exists as a real tag at 8dd82d4f, so the published release is marked in history and the baseline entry is no longer true.
• The baseline entry is already gone from main — zero occurrences of @socketsecurity/lib@6.5.2.
• main has moved to 6.5.3, released today, which is why the version and CHANGELOG hunks now conflict.

Rebasing would leave nothing behind but a version downgrade, so there is no salvageable remainder.