feat(ci): gate the publish on clean-install AND upgrade-over-previous (#8953)

* feat(ci): gate the publish on clean-install AND upgrade-over-previous

`check:pack-boot` proves a fresh install boots. It does not prove the path that actually
broke us: installing over an existing version, where ~110 SQLite migrations run against a
populated database. v3.8.48 shipped as a hotfix because the published 3.8.47 crashed on
boot, and the v3.8.49 upgrade path was only ever exercised end-to-end by hand — on VPS .16,
against a real 3.8.48 install with a 165 MB database, AFTER publishing. That is backwards.

New gate (`scripts/check/check-install-upgrade.mjs`), wired into npm-publish.yml as step 12,
BEFORE `npm stage publish` — so a broken upgrade never reaches the registry and a staged
package that is never approved simply expires, with no `npm deprecate` needed:

- Phase A: fresh prefix + fresh DATA_DIR, install the packed tarball, boot, health.
- Phase B: fresh prefix + fresh DATA_DIR, install the PREVIOUS published version, boot it
  (creates + migrates the DB), stop, install the tarball over the SAME prefix, boot against
  the SAME DATA_DIR. Asserts no table present before the upgrade was dropped.
- Schema convergence, and its DIRECTION is the whole point:
    fresh − upgraded ≠ ∅  → FAIL. Structure a clean install creates but an upgrade does not
                            means every existing user is missing it. Not allowlistable.
    upgraded − fresh ≠ ∅  → residue; fails only when NEW (allowlist carries the known ones).

A naive symmetric check would either block every release on harmless residue or, if relaxed,
let the dangerous direction through. Measured on VPS .16 (2026-07-30): a real 3.8.48 install
upgraded to 3.8.49 ended with 117 tables against 116 for a clean 3.8.49 install — the extra
being `cache_metrics`, recorded in config/quality/install-upgrade-allowlist.json with the
measurement. Both installs healthy, zero `no such table` in 150 log lines.

`evaluateConvergence` is exported and pure so the asymmetry is testable without packing,
installing or booting anything (same reason check-test-masking exports its helpers):
tests/unit/check-install-upgrade-convergence.test.ts, 8 cases, ~6ms.

A previous version that fails to boot degrades to a warning — a historically bad publish
must not block the current one. Uses node:sqlite (Node 24, already the publish job's
runtime): no new dependency.

* fix(ci): require the reused next-build artifact to come from this repository

CodeQL raised actions/artifact-poisoning/critical on the `next-build` fast path
this PR builds on (#8941). The finding is real and it sits on the path that
produces the published npm tarball.

The step picks a CI run by querying the runs API for `head_sha` and filtering on
`name == "CI" and conclusion == "success"`. That query also returns
`pull_request` runs from FORKS: they execute in this repository's context and
upload their own `next-build`, built from fork-controlled source. Measured
today, 57 runs in this repo have a `head_repository` other than the repo itself.
So the selection trusted bytes by coincidence of commit SHA — anything that made
a fork's head commit coincide with the publish commit could put attacker-built
bytes on npm.

Adds `and .head_repository.full_name == env.REPO` to the selection. Provenance
is now explicit; `head_sha` still carries tree-equality. Verified against the
live API using the expression extracted from the workflow itself — the same
single run (30518663668) is selected either way for the current tip, so the fast
path keeps working while every fork run is excluded.

Not a dismissal (hard rule #14) — the clause removes the flagged trust.

    node --import tsx/esm --test tests/unit/npm-publish-artifact-provenance.test.ts
    # 3 pass, 0 fail        (base: 2 pass, 1 fail)

---------

Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>

.github/workflows/npm-publish.yml

@@ -159,6 +159,17 @@ jobs:
       # `head_sha` is the tree-equality guarantee: same commit, same tree.
       # Best-effort by design (retention is 1 day): every miss falls through to the build
       # step below, which is why the dynamic runner above matters as the backstop.
+      #
+      # The `head_repository.full_name == env.REPO` clause is a supply-chain guard, not a
+      # filter refinement. This artifact becomes the published npm tarball. `pull_request`
+      # runs from forks execute in THIS repository's context and upload their own
+      # `next-build` built from fork-controlled source, and the runs API returns them for a
+      # matching `head_sha` — 57 such runs exist in this repo today. Without the clause,
+      # anything that made a fork's head commit coincide with the publish commit could put
+      # attacker-built bytes on npm. Requiring the run to originate from this repository
+      # excludes every fork run while keeping the fast path intact (verified: the same
+      # single run is selected either way for the current tip).
+      # CodeQL: actions/artifact-poisoning/critical.
       - name: Reuse CI's next-build artifact (skips the heavy rebuild)
         if: steps.resolve.outputs.skip != 'true'
         continue-on-error: true
@@ -169,7 +180,11 @@ jobs:
         run: |
           set -uo pipefail
           RUN=$(gh api "repos/$REPO/actions/runs?head_sha=$HEAD_SHA&per_page=100" \
-            --jq '[.workflow_runs[] | select(.name == "CI" and .conclusion == "success")] | .[0].id // empty') || RUN=""
+            --jq '[.workflow_runs[]
+                   | select(.name == "CI"
+                            and .conclusion == "success"
+                            and .head_repository.full_name == env.REPO)]
+                  | .[0].id // empty') || RUN=""
           if [ -z "$RUN" ]; then
             echo "::notice::no successful CI run for $HEAD_SHA — falling back to a full build"
             exit 0
@@ -223,6 +238,18 @@ jobs:
         if: steps.resolve.outputs.skip != 'true'
         run: npm run check:pack-boot
 
+      # The boot-smoke above proves a CLEAN install boots. It does not prove the path that
+      # actually broke us: installing over an existing version, where ~110 SQLite migrations
+      # run against a populated database. v3.8.48 shipped as a hotfix because the published
+      # 3.8.47 crashed on boot, and the v3.8.49 upgrade path was first exercised end-to-end
+      # by hand on a real 3.8.48 box (VPS .16) — after publishing, which is exactly backwards.
+      # Runs BEFORE `npm stage publish` so a broken upgrade never reaches the registry at all;
+      # a staged package that is never approved simply expires, with no `npm deprecate` needed.
+      - name: Prove clean-install AND upgrade-over-previous both boot
+        if: steps.resolve.outputs.skip != 'true'
+        timeout-minutes: 30
+        run: npm run check:install-upgrade
+
       # WS1.3 (D2, v3.8.49 plan): STAGED publishing by default — `npm stage publish`
       # parks the exact bytes on the registry WITHOUT making them installable; the
       # owner then verifies and approves with 2FA (`npm stage approve`), moving the