packaging/windows: fix build watcher never firing, correct earlier

BTRFS misdiagnosis in README

The build watcher was registered as a SYSTEM-context Scheduled Task
(schtasks /ru SYSTEM). Confirmed on a real run this never actually
works: Z:\ (the /shared mount) is mapped per interactive session, a
SYSTEM task has no session of its own and can't see it, so
watch_build.bat spun forever on its own "if not exist Z:\" wait -- a
build request sat unclaimed for hours with zero indication anything
was wrong. Fixed with an All-Users Startup-folder entry instead, which
runs in whichever user's session actually logs in.

Also correcting the README's earlier "BTRFS boot-loop" entry: that was
a misdiagnosis from reading the text log alone (repeated
"loading/starting Boot0004" lines). Actually looking at the noVNC
screen showed genuine, progressing Windows Setup the whole time --
Setup legitimately reboots the VM multiple times, each one re-prints
those same firmware lines. The chattr +C fix stays (real, independently
documented dockur/QEMU/BTRFS caveat) but likely wasn't fixing an actual
problem that time.

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

packaging/windows/README.md

@@ -19,15 +19,25 @@ happen at http://localhost:8006 (dockur's noVNC viewer) if it stalls.
 - **SELinux blocks the bind mounts** ("Storage folder (/storage) is not
   writeable!") — fixed with `:Z` on every volume in `docker-compose.yml`.
   Harmless no-op on a host without SELinux.
-- **BTRFS + QEMU disk images boot-loop Windows Setup for hours** with no
+- **The repeated "loading/starting Boot0004" log lines are NOT a boot
-  error, just the same boot-manager log lines repeating forever and the
+  loop** — that was an earlier misdiagnosis here (blamed on BTRFS+QEMU,
-  disk barely growing — dockur/windows warns about this itself
+  "fixed" with `chattr +C` on `storage/`). Checked the actual noVNC
-  ("you are using the BTRFS filesystem for /storage, this might
+  screen instead of just the text log and it was genuine, progressing
-  introduce issues with Windows Setup!"), and on this host it wasn't
+  Windows Setup the whole time ("This might take a few minutes" →
-  idle chatter. Fixed by disabling copy-on-write on `storage/` before
+  "Please keep your PC on and plugged in" → desktop) — Setup legitimately
-  the VM ever writes to it (`chattr +C`, only affects files created
+  reboots the VM multiple times, each one re-prints those same firmware
-  after it's set, so it needs an empty directory) — `build_windows.sh`
+  log lines. The `chattr +C` disables copy-on-write for the VM's disk
-  now does this itself on every run. No-op on a non-btrfs filesystem.
+  image regardless (a real, independently-documented dockur/QEMU/BTRFS
+  caveat), so it's staying, but it likely wasn't fixing an actual
+  problem this time. **Lesson: check the screen, not just the log,
+  before concluding something's stuck.**
+- **The build watcher registered as a SYSTEM-context Scheduled Task
+  never fires in practice**: `Z:\` (the `/shared` mount) is mapped per
+  interactive session, invisible to a task with no session of its own,
+  so it spun forever on `watch_build.bat`'s own `if not exist Z:\`
+  wait — confirmed by a build request sitting unclaimed for hours.
+  Fixed in `install.bat`: an All-Users Startup-folder entry instead,
+  which runs in whichever user's session actually logs in.
 
 ## How it fits together
 

packaging/windows/oem/install.bat

@@ -61,12 +61,18 @@ powershell -NoProfile -Command ^
   "Expand-Archive -Path 'C:\wix311-binaries.zip' -DestinationPath 'C:\wix' -Force"
 del C:\wix311-binaries.zip
 
-REM -- Register the build watcher to run at every boot from here on, plus
+REM -- Register the build watcher to run at every login from here on,
-REM kick it off right now too (ONSTART won't retroactively fire for this
+REM plus kick it off right now too (a fresh login won't retroactively
-REM already-in-progress boot). Runs as SYSTEM so it works with no user
+REM fire for this already-logged-in session). Deliberately an All-Users
-REM logged in.
+REM Startup-folder entry, NOT a SYSTEM-context Scheduled Task: confirmed
-call :log "registering build watcher ..."
+REM on a real run that a /ru SYSTEM task can't see Z:\ at all and spins
-schtasks /create /tn "FenigmaBuildWatcher" /sc onstart /ru SYSTEM /rl HIGHEST /tr "C:\OEM\watch_build.bat" /f >> C:\OEM\install.log 2>&1
+REM forever on watch_build.bat's own "if not exist Z:\" wait -- Z:\ (the
+REM /shared mount) is mapped per INTERACTIVE session, invisible to a
+REM SYSTEM task with no session of its own. Startup-folder entries run
+REM in whichever user's session actually logs in, inheriting their
+REM drive mappings correctly.
+call :log "registering build watcher (Startup folder) ..."
+copy /y C:\OEM\watch_build.bat "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\FenigmaBuildWatcher.bat" >> C:\OEM\install.log 2>&1
 start "" cmd /c C:\OEM\watch_build.bat
 
 call :log "provisioning done"