fix(desktop): align the Electron version across every place it is pinned

[dizhaky]

Fixes the red desktop-electron-pin test on main.

The defect

apps/desktop/package.json declared the dependency as electron: 41.10.3 while build.electronVersion still read 40.10.2. Those fields do different jobs:

• the dependency + lockfile decide what npm ci installs — what tests run against, and what electron . uses in dev;
• build.electronVersion decides which Electron dist electron-builder downloads and packages.

So the shipped app was a different Electron from the tested one. Code using a 41-only API would pass CI and fail in the packaged build. desktop-electron-pin.test.ts was written for exactly this drift and is red on main.

A fourth reference, which no test covered

Root package.json carries allowScripts, keyed by name@version, and it still said electron@40.10.2. Electron's postinstall is what fetches the actual binary, so a stale key means the allowlist silently stops covering it.

Nothing in this repo reads that field — no lavamoat dependency, no script; it appears only as data in the root and website/ manifests. That is precisely why the drift went unnoticed, and it's the part most worth a second opinion from whoever owns the external consumer.

Fix

Aligned up, to what is actually installed:

place	before	after
apps/desktop/package.json dependency	41.10.3	unchanged
apps/desktop/package.json build.electronVersion	40.10.2	41.10.3
root package.json allowScripts	electron@40.10.2	electron@41.10.3
package-lock.json resolution	41.10.3	unchanged

Aligning down instead would mean reverting the dependency and regenerating the lockfile — larger, and the resolution couldn't be verified offline here. Up is also the safer direction on the merits: ship what you test.

A fourth assertion now pins the allowScripts key so the next bump can't leave it behind. It returns early when there's no electron key at all, since not pinning there is a choice rather than drift.

Verification

There's no node_modules in this sandbox, and installing the monorepo would drag in the known react/react-dom skew. This test reads only two JSON files and imports nothing at runtime, so I executed its assertions directly in Node against the real files rather than claiming a vitest run I didn't do:

before:  PASS exactly pinned
         FAIL matches build.electronVersion
         PASS lockfile resolves the pin
after:   4 passed, 0 failed

Positive control: reverting only the allowScripts line fails only the new assertion. node --experimental-strip-types --check parses the modified test file.

A correction to something I published

In #156's body and in docs/system-log/2026-08-08.md I wrote that this mismatch "arrived in 7e38fa5 (#155, a dependabot bump)". That was wrong. #155 bumped dompurify and js-yaml and never touched electron. git log -L pointed at it only because this clone is shallow and 7e38fa5 is the graft boundary, so the whole file reads as added there. When the drift actually entered isn't determinable from this clone. The correction is recorded in the new log entry.

Follow-up not in this PR

The native-extract-zip install path is already live. The lockfile resolves @electron/get@5.0.0 and @electron-internal/extract-zip@1.0.4 — the napi path whose win32-x64 binding is what the pin test's own header blames for ERR_DLOPEN_FAILED on some Windows hosts. That arrived with the 41.x dependency and is unchanged here: this PR doesn't add the risk, but it doesn't remove it either. Worth a Windows install check before the next release.

---

Generated by Claude Code