Stop an ordinary merge from arming the release gate

[LakshmanTurlapati]

Why

release.yml triggers on every push to main, and the release chain is gated only on hasChangesets == 'false'. That is satisfied by any ordinary merge, not just a Version Packages merge — so every commit to main runs the full chain and parks a deployment at the npm-production gate.

Approving one cannot succeed. The sealed commit no longer matches the commit named in the published packages' provenance:

[REGISTRY_PROVENANCE] @full-self-browsing/concierge provenance repository, workflow, commit, or run drifted

That refusal is correct — the publisher must not certify bytes it did not produce, and RELEASING.md already says resumption must be "from the exact same commit". But it leaves a gate on main that can only ever fail.

This was demonstrated by merging #11: version, verify, seal, and browser_e2e all passed, publish was approved, and it failed on exactly that check. The registry was untouched.

What changed

• scripts/release/published.mjs (new) asks the registry whether every package in the fixed set already carries the working tree's version, and prints { version, allPublished, missing }.
• verify now also requires allPublished == 'false'. seal, browser_e2e, and publish all descend from verify, so they skip with it and no deployment is created.
• The check runs before the Changesets step, which rewrites manifests for the Version Packages PR — the question is about the commit that was pushed, not about what a pending release would become.

Fail direction

An unreachable registry reports not published, so the chain runs. A registry the script cannot read is one it cannot make claims about, and the worst case of proceeding is the pending deployment this change exists to avoid — whereas wrongly reporting "published" would silently skip a real release. Partial publication reports not-published for the same reason, which keeps the documented resume path reachable.

Verification

Tested against the live registry in both directions:

$ node scripts/release/published.mjs                    # all five at 0.4.0
{"version":"0.4.0","allPublished":true,"missing":[]}

$ # with core temporarily bumped to 0.4.1
{"version":"0.4.1","allPublished":false,"missing":[ ...all five... ]}

check.mjs all and check.mjs workflow pass, and the workflow YAML parses with the expected verify.if and job outputs.

Behaviour after this lands: merges to main skip the release chain entirely; a Version Packages merge still runs it, because the new version is not yet on the registry.