feat(packaging): a Light installer target with no bundled node runtime

MeshBay Light ships the Electron client + UI only -- no PyInstaller node
freeze, no ffmpeg, no service install/autostart. Two standalone
electron-builder configs (Full via package.json's build field, Light via
electron-builder.light.yml passed with --config, which reads only that
file -- confirmed against app-builder-lib's own config loader) rather than
one config branching on a flag.

build-win-common.ps1 holds the steps both orchestrators share (Node check,
npm ci, Electron bump, sync-ui) so build-win.ps1 (Full) and the new
build-win-light.ps1 cannot drift apart; build-win.ps1 is refactored to
dot-source it with no behavior change (rebuilt and diffed byte-identical
output).

installer-light.nsh keeps the one thing Light still needs -- an
unconditional firewall rule, since the client listens too -- and none of
the service-mode/autostart machinery installer.nsh carries, which has
nothing to gate without a bundled node.

dist-light/ (Light's own electron-builder output dir) gets its own
.gitignore line since the bare dist/ rule does not match it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 64 insertions, 0 deletions

diff --git a/packaging/win/build-win-common.ps1 b/packaging/win/build-win-common.ps1
new file mode 100644
index 0000000..e60abc5
--- /dev/null
+++ b/packaging/win/build-win-common.ps1
@@ -0,0 +1,64 @@
+<#
+.SYNOPSIS
+    Steps shared by build-win.ps1 (Full) and build-win-light.ps1 (Light).
+
+.DESCRIPTION
+    Dot-sourced, not run directly -- it defines functions, it does not call
+    them. The two orchestrators differ only in whether they freeze a node
+    runtime and which electron-builder config they hand to the final step;
+    everything before that (Node version check, npm ci, the Electron-bump
+    policy, sync-ui) is identical, and living in one place means it cannot
+    drift between the two the way a copy-paste would.
+
+    Every function assumes it runs from packages/meshbay-client (both
+    orchestrators Push-Location there first).
+#>
+
+function Step($msg) { Write-Host "==> $msg" -ForegroundColor Cyan }
+
+function Assert-NodeVersion {
+    if (-not (Get-Command node -ErrorAction SilentlyContinue)) {
+        throw "Node.js not found. Install Node 22 or newer from nodejs.org."
+    }
+    $nodeMajor = [int](& node -e "process.stdout.write(String(process.versions.node.split('.')[0]))")
+    if ($nodeMajor -lt 22) { throw "Node $nodeMajor is too old -- need 22 or newer for Electron" }
+    Step "Node $(& node --version)"
+}
+
+function Invoke-NpmCi {
+    Step "npm ci"
+    & npm ci --ignore-scripts
+    if ($LASTEXITCODE -ne 0) { throw "npm ci failed" }
+}
+
+# Chromium-CVE policy: build against the latest Electron release unless
+# -NoElectronBump was passed. Writes package.json + package-lock.json when it
+# actually bumps something (that is by design -- commit the new pin); the
+# Chromium download itself always runs, bump or not, same as before this was
+# factored out.
+function Invoke-ElectronBump {
+    param(
+        [switch]$NoElectronBump,
+        [Parameter(Mandatory = $true)][string]$WinDir
+    )
+    if (-not $NoElectronBump) {
+        Step "checking for a newer Electron"
+        $bumped = & node (Join-Path $WinDir "bump-electron.mjs")
+        if ($LASTEXITCODE -ne 0) { throw "electron bump failed" }
+        if ($bumped) {
+            Write-Host "    Electron -> $bumped  (package.json + lock updated, commit them)" -ForegroundColor Yellow
+        } else {
+            Write-Host "    Electron is already current"
+        }
+    }
+
+    Step "downloading Electron's Chromium"
+    & npm approve-scripts electron 2>$null
+    & node node_modules/electron/install.js
+}
+
+function Invoke-SyncUi {
+    Step "npm run sync-ui"
+    & npm run sync-ui
+    if ($LASTEXITCODE -ne 0) { throw "sync-ui failed" }
+}