fix(ci): stop source-building better-sqlite3 in the desktop build

[Weegy]

Problem

The Windows leg of desktop-apps has failed on every release since v0.64.0 (2026-08-11). No .exe installer has shipped since v0.63.0.

This stayed quiet because nothing else broke: the release job, publish-images, and the macOS/Linux installers are all green. Only the windows-latest matrix entry goes red — which is enough to paint every auto-release run as failed.

Confirmed across the last 10 failing runs: identical job, identical step.

desktop-apps / build (windows-latest, --win) :: Build middleware kernel
npm error command cmd /d /s /c node-gyp rebuild
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer

Release	Windows .exe
v0.63.0 (2026-08-10)	✅
v0.64.0 … v0.70.0	❌ (0 assets)

Root cause

better-sqlite3 was bumped 12 → 13 in a42b1d5 (#615), merged 2026-08-11 06:20 UTC. The first red auto-release ran 07:49 UTC the same day.

v13 is N-API and ships prebuilt binaries for every platform inside its own tarball — including prebuilds/win32-x64.node. That is why it declares gypfile: false: "do not build me". npm ignores that field and synthesises install: node-gyp rebuild regardless, purely because a binding.gyp is present in the package.

macOS and Linux merely waste time on that pointless compile. windows-latest has no Visual Studio node-gyp can locate, so npm ci fails outright.

This exact defect was already diagnosed and fixed for the container build in #615 — the root Dockerfile carries npm ci --ignore-scripts plus an explicit npm rebuild argon2 esbuild, with a comment spelling out the same reasoning. The desktop workflow was simply missed. This PR applies the identical, already-proven treatment.

Changes

1. npm ci --ignore-scripts --no-audit --no-fund + npm rebuild argon2 esbuild in Build middleware kernel, mirroring the Dockerfile. argon2 and esbuild are the only middleware packages with a real install script (fsevents is macOS-only and optional).

2. Drop GYP_MSVS_VERSION: '2022' — dead twice over. It never had any effect (node-gyp reads npm_config_msvs_version; the failing run logs "msvs_version not set from command line or npm config"), and the value is wrong anyway: the runner image now ships Visual Studio 18, which node-gyp 11.5.0 rejects as unknown version "undefined". Worth stressing: "just install MSVC" would not have been a reliable fix.

3. Replace Provision better-sqlite3 for Electron with the verification it already contained. That step could only fail or no-op:

   • upstream publishes no GitHub release assets for v13, so prebuild-install -r electron always missed and fell through to a source rebuild — which needs the very toolchain Windows lacks;
   • and even when that rebuild succeeded, its artefact was never loaded: v13's loader (lib/binding.js) resolves prebuilds/ first and only falls back to build/Release/.

   So today's macOS/Linux builds already run on the bundled prebuild, not on the electron-rebuild output. Removing the rebuild changes nothing observable there.

Verification

Reproduced and verified locally against better-sqlite3@13.0.3:

• npm ci (and npm install) run node-gyp rebuild despite gypfile: false being present in both the registry manifest and the tarball's own package.json. (Note: the Dockerfile comment claims npm install honours the field — measured on npm 11.16.0, both ignore it. Not corrected here to keep this diff scoped.)
• The published tarball contains prebuilds for all 8 platform/arch combos, win32-x64.node included.
• npm ci --ignore-scripts produces no build/ directory, invokes no node-gyp, and the module loads and executes SQL from the bundled prebuild.

The Electron ABI check is deliberately kept as the real gate: if the N-API/ABI-stability assumption is ever wrong, the build fails there rather than crashing the kernel at boot in the shipped app.

Merge check: the first auto-release run after merge should attach a Windows .exe again. Worth watching, since the Windows leg has not progressed past step 1 in two days — web-ui and desktop carry no better-sqlite3 and no node-gyp packages, so they are expected to pass, but that is an expectation this PR cannot prove on its own.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}