Approve the bump PR's own build, and correct the parser-retention story

[sqlparser]

Two things, both found while landing #51 (the 4.1.11 → 4.2.6 bump).

The bump PR's build never actually runs

nightly.yml opens the bump PR partly so that "the push-triggered build.yml [gets] a chance to disagree". It does not get one.

GitHub gates workflow runs from first-time contributors — this repository's policy is first_time_contributors, read back from /actions/permissions/fork-pr-contributor-approval — and github-actions[bot] counts as one. So the pull_request run on a bump branch is created in action_required at 0s and never starts.

It is quiet in the worst way: gh pr checks reports "no checks reported", which reads as this workflow does not apply here rather than this workflow is blocked. #51 sat like that until someone happened to look. Merging in that state loses every part of build.yml the nightly does not already duplicate — the JDK 8 build, the pre-commit hook test, and the whole windows-bat job.

The latest job now finds that run and approves it. When the token cannot, the notice is posted on the PR itself rather than as a warning annotation on an otherwise-green nightly, since that is the same kind of thing nobody reads.

All reachable paths were exercised by extracting the step's script and running it against the live API:

path	result
run found, not gated	finds run 32689079075 correctly, not gated, nothing to approve, exit 0
no run found	warns with the actions URL, exit 0
gated, approve fails	warning plus a correctly rendered PR comment carrying the run URL

The approve call itself has no gated run to test against, but it is the same POST .../approve that unblocked #51 by hand — with a personal token rather than GITHUB_TOKEN, which is exactly why the fallback exists.

There is a one-API-call alternative: setting the policy to first_time_contributors_new_to_github. It also loosens fork-PR approval for genuine first-time human contributors on a public repo, so it is left as a deliberate decision rather than folded in here.

The retention story was wrong

The README said 4.1.9 was the only version left on the server. Measured 2026-08-24:

version	.jar / .pom
4.1.4 – 4.1.8	404
4.1.9, 4.1.11, 4.2.6	200

maven-metadata.xml lists exactly those three, so it is pruned in step with reality rather than left stale, and 4.1.11 went on resolving after 4.2.6 was published on 2026-08-23. The five that vanished on 2026-07-28 are still gone and are not coming back — but that was a deliberate recall, which the README already documents correctly. Only the "residue" sentence and the nightly section needed correcting.

(The same correction was made to CLAUDE.md, which is gitignored here, so it is not in this diff.)

🤖 Generated with Claude Code

https://claude.ai/code/session_01UK3dBXFXqiDRYJxz1YxWCr