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>

2 files changed, 25 insertions, 2 deletions

diff --git a/docs/PACKAGING-GUIDE.md b/docs/PACKAGING-GUIDE.md
index fdc0a57..a9aa7fc 100644
--- a/docs/PACKAGING-GUIDE.md
+++ b/docs/PACKAGING-GUIDE.md
@@ -127,6 +127,27 @@ firewall rules and the boot-time service task with one administrator
 confirmation (none if neither is there). None of this touches
 `%LOCALAPPDATA%\meshbay\` (the keystore).
 
+### Microsoft Store version
+
+The same client and node, installed from the Microsoft Store. It never asks
+for administrator rights, and Windows itself manages what the installer above
+sets up with scripts:
+
+- **Firewall**: the rules for the node are part of the package. Windows adds
+  them at install, keeps them through updates and removes them with the app.
+- **When the node runs**: **Only while MeshBay is open** (the default) or
+  **At sign-in**, chosen on the **Node** page. At sign-in is the
+  *MeshBay Node* entry of **Settings → Apps → Startup**; switching it off
+  there is the same as choosing **Only while MeshBay is open**, and the Node
+  page cannot switch it back on until it is on there again.
+- **At boot, before anyone signs in, is not available**: it needs the
+  `.exe` installer above.
+- **`meshbay-node` in a terminal** works as with the installer.
+
+Runtime data lives in the same `%LOCALAPPDATA%\meshbay\` and survives
+uninstalling the app. Uninstall from **Settings → Apps**; it removes the
+firewall rules and the sign-in entry with it.
+
 ### Build from source
 
 See [`packaging/win/README.md`](../packaging/win/README.md). On a machine with
diff --git a/docs/WINDOWS-PORT.md b/docs/WINDOWS-PORT.md
index 1894706..7e13aa0 100644
--- a/docs/WINDOWS-PORT.md
+++ b/docs/WINDOWS-PORT.md
@@ -723,5 +723,7 @@ uses a Scheduled Task (S4U logon), not `pywin32`/NSSM — see §5.3.
   packaging, no daemon lifecycle, no testing.
 - **Windows ARM** — not considered. Electron supports it; Python and
   ffmpeg availability would need checking.
-- **Windows Store / MSIX** — not planned for v1. NSIS per-user installer
-  is the target.
+- **Windows Store / MSIX** — built since (`npm run dist:win:msix`,
+  `packaging/win/electron-builder.msix.yml`, which says what the manifest
+  declares in place of the NSIS scripts). Starting at boot stays the NSIS
+  installer's.