Follow-up from 0cec298 (fix(ci): use npm install instead of npm ci to route around an upstream npm bug)

`.github/workflows/release.yml`'s four frontend-install steps (`test`, `build-macos-arm64`, `build-windows`, `build-linux`) use `npm install` instead of `npm ci`, specifically to route around a currently-open, unmerged upstream npm bug:

• npm/cli#7622 — "npm ci erroneously installs optional OS-constrained transitive dependency through direct shrinkwrap dependency"
• Fix PR: npm/cli#8310 — open, unmerged as of 2026-08-09

Symptom this repo hit: `npm ci` failed on the Linux CI runner with `EBADPLATFORM: Unsupported platform for @esbuild/netbsd-arm64@0.28.2` — caused by `vitest`'s optional peer dependency on `esbuild` (which ships ~30 platform-specific `optionalDependencies` of its own). Reproduced with lockfiles generated by both npm 11.17.0 and npm 10.8.2; did not reproduce locally on darwin/arm64 with either version — Linux-runner-specific.

Why `npm install` instead of a version bump: upgrading npm wouldn't have helped since the fix isn't released yet. `npm install` follows a different code path for resolving optional dependencies than `npm ci` and isn't subject to this specific bug.

What to do once this is fixed upstream

1. Confirm fix(arborist): don't checkEngine/checkPlatform for extraneous deps npm/cli#8310 (or an equivalent fix) has shipped in a released npm version.
2. Bump `actions/setup-node`'s `node-version` if needed to pick up a Node release bundling the fixed npm, or add an explicit `npm install -g npm@` step.
3. Revert all four `npm install` → `npm ci` in `release.yml`, restoring the stricter lockfile-sync guarantee.
4. Remove this issue.

Trade-off while this stays open

`npm install` won't fail loudly if `wails-app/frontend/package-lock.json` drifts out of sync with `package.json` — it'll just silently reconcile at install time in CI instead of hard-failing the way `npm ci` would. Not a correctness risk for the shipped app (the actual installed versions still satisfy `package.json`'s ranges either way), but it's a weaker drift-detection guarantee than before.