feat(packaging): the Store package declares what the NSIS scripts do

A test-signed install of the MSIX build, in the WindowsApps folder a Store
install uses, showed that every script-made piece of the NSIS model breaks
there, because each names the install folder and every update deletes it:
the firewall rules went stale, the PATH entries piled up pointing at deleted
folders, and the Startup-folder .vbs was refused ("Permission denied") right
after sign-in. The network capabilities the manifest declared covered
nothing: they make rules for sandboxed apps only, and a listener in the
package still got the Windows firewall prompt. The package's own startup
task was on by default, started the node whatever mode the Node page said,
and ran the console executable, whose window stopped the node when closed.

The package now declares what Windows then creates at install, carries
across updates and removes with the app, all without an administrator
prompt (each measured on the real install, through an update and a reboot):

- firewall rules for the node, in a custom manifest template, since only a
  package-level element can hold them;
- the startup task, off by default, running meshbay-nodew.exe, a new build
  of the daemon without a console;
- an execution alias for meshbay-node.exe, so the app adds no PATH entry.

The node's CLI switches the startup task (platform.startup_task, ctypes over
the WinRT ABI): Windows gives the package's identity to the executables in
it, not to a powershell.exe the app starts, which got "Element not found".
`meshbay-node autostart install | remove | status` therefore works in the
Store package from the app and a terminal alike; the app caches the answer,
since the Node page polls. Starting at boot stays the .exe installer's: the
Store package offers no service mode, and the CLI refuses `service install`
there. Process listings count both image names.

The Node page's status poll cleared the message of a refused action within
five seconds; the two errors are kept apart now (all Windows builds).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 33 insertions, 49 deletions

diff --git a/packaging/win/electron-builder.msix.yml b/packaging/win/electron-builder.msix.yml
index d3adad6..577e039 100644
--- a/packaging/win/electron-builder.msix.yml
+++ b/packaging/win/electron-builder.msix.yml
@@ -1,8 +1,22 @@
-# Standalone electron-builder config for the "MSIX" Windows target: same
-# feature set as Full (bundled node + ffmpeg), packaged for Microsoft Store
-# submission instead of NSIS. The package carries none of installer.nsh's
-# elevation logic: an AppX/MSIX install never elevates, by design. What is
-# still unverified here is called out at each declaration below.
+# Standalone electron-builder config for the "MSIX" Windows target: the
+# bundled node + ffmpeg, packaged for Microsoft Store submission instead of
+# NSIS.
+#
+# What the NSIS build does with scripts -- firewall rules, a Startup-folder
+# launcher, a boot task, a PATH entry -- this package DECLARES in its manifest,
+# and Windows creates it at install, carries it across updates and removes it
+# with the package, all without an administrator prompt. Scripts could not do
+# that job here: everything they write names the install folder, and a Store
+# install lives in C:\Program Files\WindowsApps\MeshBay.MeshBay_<version>_...,
+# which each update deletes. Measured on a real install (2026-10-08):
+#   - firewall: build/appx-manifest.xml declares the node's rules;
+#   - at sign-in: build/appx-extensions.xml declares a startup task, off by
+#     default, that the node's CLI switches (`meshbay-node autostart`),
+#     for the app's Node page and a terminal alike;
+#   - `meshbay-node` in a terminal: an execution alias, also in that file;
+#   - at boot, before anyone signs in: not offered. It needs a boot task,
+#     created elevated and left behind on uninstall; that is the .exe
+#     installer's job.
 #
 # Deliberately NOT layered onto package.json's `build` field, same reasoning
 # as electron-builder.light.yml: --config reads ONLY this file, so nothing
@@ -42,33 +56,15 @@ win:
   icon: build/icon.ico
   artifactName: "MeshBay-${version}.${ext}"
   extraResources:
-    # Same bundle as Full (package.json's own build.win.extraResources) --
-    # this target drops NSIS, not the node/ffmpeg runtime or the two service
-    # scripts. service-mode.ps1 in particular still works unmodified: it is
-    # invoked from main.js's winElevateServiceMode() on demand, from the
-    # running (unelevated) app, not from an installer step -- that path
-    # already existed before this target did (see "the other door" comment
-    # in src/main.js) and needs nothing new here beyond the file being
-    # present to find.
+    # The node runtime as Full ships it, both executables: meshbay-node.exe
+    # (CLI, and what the app starts) and meshbay-nodew.exe (no console, for
+    # the startup task). No scripts: firewall.ps1, the service scripts and
+    # ensure-node-path.ps1 are the manifest's job here (see the top of this
+    # file), and main.js offers no service mode without service-mode.ps1.
     - from: node-runtime
       to: node-runtime
       filter:
         - "**/*"
-    - from: ../../packaging/win/firewall.ps1
-      to: firewall.ps1
-    - from: ../../packaging/win/service.ps1
-      to: service.ps1
-    - from: ../../packaging/win/service-mode.ps1
-      to: service-mode.ps1
-    # Full's own installer adds node-runtime\ to the per-user PATH at install
-    # time (build/installer.nsh's customInstall) -- an unelevated HKCU write,
-    # never blocked by the no-elevation rule this target is built around, but
-    # MSIX has no install-time hook at all to run it from. main.js's
-    # winEnsureNodeOnPath() calls this itself on first launch instead
-    # (found missing by actually sideloading a build and checking, not
-    # anticipated in the original plan).
-    - from: ../../packaging/win/ensure-node-path.ps1
-      to: ensure-node-path.ps1
     # The application's own licence, beside the app (Electron's LICENSE and
     # LICENSES.chromium.html are put next to the exe by electron-builder).
     - from: ../../LICENSE
@@ -99,26 +95,14 @@ appx:
     - it-IT
     - nl-NL
     - pl-PL
-  # Both are the "common" (general, non-restricted) capability group per
-  # app-builder-lib's AppxCapabilities.js -- no special Store justification
-  # needed, unlike the `rescap`-namespaced restricted ones. Matches
-  # firewall.ps1's own rules, which are `-Profile Any` (private AND public
-  # network). Whether Windows Firewall actually auto-exempts a full-trust
-  # packaged app on the strength of these declarations -- eliminating the
-  # elevation firewall.ps1 exists for entirely -- is an open item: verify
-  # live before relying on it, the declaration alone only proves the
-  # manifest is well-formed.
-  capabilities:
-    - internetClientServer
-    - privateNetworkClientServer
-  # windows.startupTask, the MSIX-native equivalent of the NSIS "at sign in"
-  # mode's Startup-folder .vbs (main.js's WIN_STARTUP_VBS) -- but pointed at
-  # the node daemon, not the Electron shell, which is what `addAutoLaunchExtension:
-  # true` would do instead (it always targets the package's own main
-  # executable, per AppxTarget.js's `executable` macro -- there is no config
-  # switch to point it at a different bundled exe). build/appx-extensions.xml
-  # declares that extension by hand for exactly this reason. Whether
-  # Windows actually launches a *non-primary* bundled exe through this
-  # mechanism is the other open item -- untested until sideloaded.
+  # Execution aliases need Windows 10 1709; 1809 is the oldest still
+  # serviced. electron-builder's default (10.0.14316.0, for both) predates both.
+  minVersion: 10.0.17763.0
+  maxVersionTested: 10.0.26100.0
+  # The stock template plus the package-level firewall rules.
+  customManifestPath: build/appx-manifest.xml
+  # The startup task and the execution alias. Not addAutoLaunchExtension:
+  # that one always starts the package's main executable, the Electron shell,
+  # where "at sign-in" means the node.
   customExtensionsPath: build/appx-extensions.xml
   showNameOnTiles: false