fix: bump Electron to 43.4.1 and nanoid to 3.3.18

[mrxmoex]

Summary

• Bump nanoid@^3 (and the website pin) from 3.3.17 to 3.3.18 for GHSA-2v37-7h3g-55p8. Clears the web / ui-tui / website audits.
• Bump desktop Electron 40.10.2 → 43.4.1 for GHSA-9f4c-93c8-jc8g (not patched on any 40.x). Same @electron/get@^5 + @electron-internal/extract-zip tree; lockfile splice only, peer: true count unchanged at 109.
• Keep allowScripts in lockstep (electron@43.4.1). Electron 42+ has no postinstall; install.js still fills dist/ (Hermes _redownload_electron_dist already calls it).
• Temporary min-release-age-exclude[]=electron until 43.4.1 is older than 14 days (published 2026-08-19).

Test Plan

• npm audit root / web / ui-tui / apps/desktop → 0
• apps/desktop/electron/desktop-electron-pin.test.ts + tests-js/allow-scripts-sync.test.ts → 7/7
• node_modules/electron/dist/electron --version → v43.4.1 (needs ELECTRON_DISABLE_SANDBOX=1 on an unpacked Linux tree)
• node-pty rebuilt against Electron 43.4.1 headers
• hermes desktop smoke / --dir pack (not run here)
• Linux WCO / frameless rounded-corner look (Electron 43 default change)

Risk

Medium — this is a desktop Chromium jump (144 → 150), not a lockfile-only bump. Chat windows already setWindowOpenHandler → deny. Unsigned macOS dev notifications may fail after the 42 UNNotification switch.

[andrexibiza]

Reviewed exact head bf035c9623d1a952ede837faab6a024a030c626a against exact current main / base 987064caa4f8845f605ac7346fed5b72fddfb21c.

The dependency graph itself looks internally coherent: the Desktop manifest and builder pin both move to Electron 43.4.1, the lock moves Electron onto @electron/get 5 + @electron-internal/extract-zip, the two vulnerable Nano ID 3.x copies resolve to 3.3.18, and the existing Nano ID 6.0.0 node is preserved. I don't see a lockfile/version-sync defect in those bytes.

I do have two merge blockers at the repository boundary.

1. This drops the already-proven Linux ARM64 packaged-layout side of the same Electron remediation. Current main still hard-codes release/linux-unpacked in apps/desktop/scripts/test-desktop.mjs. #89479 by @schmitzi8 hit the real ARM64 package and established that electron-builder emits release/linux-arm64-unpacked; that branch adds packaged-app-layout.mjs, the x64/ARM64 regression, and routes the validator through the resolved directory name. #92543 changes the Electron runtime again but leaves that known-bad validator untouched, and its own test plan says neither hermes desktop / --dir packaging nor the Linux WCO/frameless path was exercised.

That is especially material for 43: Hermes deliberately uses titleBarStyle: 'hidden' + titleBarOverlay on Linux, and Electron 43 changes Linux Window Controls Overlay/native-titlebar behavior and rounded-corner defaults. A package-major security jump should not become authoritative without the already-known ARM64 path fix plus a real packaged witness.

Required before merge: carry forward #89479's architecture-neutral packaged-layout helper/test (preserving @schmitzi8 attribution), update test-desktop.mjs to use it, and prove the exact repaired head on Linux x64 + arm64 packaged layout. A Linux WCO/custom-titlebar smoke on 43 should be part of that acceptance evidence, not left as an unchecked item.

2. The delivery owner / merge transaction is currently split in a way that will strand part of the P0 remediation. #91906 is explicitly the single dependency-remediation delivery owner, with #92046 as its trusted-main materializer. #92046 intentionally fails closed unless its landing object still has Electron 40.10.2 / the old Nano ID/PostCSS source shape, then produces the combined Electron + Nano ID + h2==4.4.1 + packaged-layout payload. If #92543 lands first, that materializer will abort by design. But #92543 does not carry uv.lock / h2 or the packaged-layout files, so it cannot simply replace #91906 as-is.

Please pick one canonical transaction before merging either lane:

• promote #92543 as the delivery payload and absorb the remaining h2 + packaged-layout obligations, then retire/retarget #91906/#92046; or
• keep #91906 as owner, update its materializer/target to Electron 43.4.1 and adopt @mrxmoex's current-main Electron/Nano ID work there, then close this branch as superseded after preserving attribution.

#90486 by @orcaspainting-dev remains Nano ID remediation provenance; #89479 remains Electron/internal-extractor + ARM64 layout provenance. #92543 is newer independent implementation work, not something to erase, but these are competing delivery shapes rather than additive PRs.

Exact-head hosted evidence is also absent right now: CI 32602178409, Docker 32602178069, and Nix 32602178131 are all action_required, so none of those workflows executed on bf035c96. The local audit/pin checks are useful, but they do not cover either boundary above.

[andrexibiza]

Dependency-remediation topology interlock

This PR is now an important current-main source candidate for the active dependency-security class. It is not being treated as disposable duplicate work.

Existing combined delivery topology:

• #91906 is the current Axl-owned combined remediation delivery object;
• #92046 is its temporary trusted-main materializer/control plane;
• historical source provenance already includes fix(deps): patch Node and Electron security advisories #89479 / @schmitzi8 and fix(deps): pin nanoid 3.3.18 under postcss (GHSA-2v37-7h3g-55p8) #90486 / @orcaspainting-dev.

Your exact head bf035c9623d1a952ede837faab6a024a030c626a is directly based on current main@987064caa4f8845f605ac7346fed5b72fddfb21c and proposes the newer Electron 43.4.1 + Nano ID 3.3.18 graph. That is materially relevant to the combined owner and should preserve your authorship if adopted.

The exact hosted runs are currently action_required with no executable jobs exposed, so this is not yet verified delivery evidence. Once independent workflow approval produces an exact-head matrix, the combined remediation should choose the strongest verified current graph rather than overwrite it with an older generated Electron target.

Scope distinction: this six-file PR does not currently carry #91906's Python h2==4.4.1 closure or its packaged-layout regression files. Those requirements remain part of the combined class unless maintainers deliberately split ownership.

No request to duplicate or reopen another remediation object. The goal is one final authoritative graph with all contributor provenance preserved.

[andrexibiza]

Topology update after reconciling the combined dependency-security owner:

This PR remains the strongest candidate source for Electron 43.4.1 and Nano ID 3.3.18, but not yet the combined closure owner. Exact head bf035c9623d1a952ede837faab6a024a030c626a still has CI/Docker/Nix in action_required with no executable job evidence exposed, so I am not treating it as verified repository truth yet.

I updated #92046 so the trusted-main materializer is now source-aware: if this PR earns exact-head verification and lands first, landing-main Electron 43.4.1 is preserved rather than overwritten by the older 41.10.3 source. Nano ID 3.3.18 is likewise accepted as landing input and reconciled into the scoped PostCSS → Nano ID 3.3.18 contract while preserving Nano ID 6. #91906 remains responsible for the missing h2==4.4.1 and packaged-layout closure.

Provenance is explicit in both #91906 and #92046: @mrxmoex / #92543 is the source edge for the newer Electron/Nano ID graph if it becomes verified landing-main truth.

Current upstream main is 530028c213ae9eed5d7f1a826451e0edf24a11d2 and still declares Electron/build 40.10.2, so no source has crossed the repository-truth boundary yet.