Confirm the Windows build pipeline works end to end: real .msi produced

The -arch x64 fix (previous commit) is confirmed live: build_errorlevel=0,
BUILD_DONE, a real 958MB FEnigma-0.1.0.msi written to Z:\dist -- the
first ever fully successful build this pipeline has produced. Copied
to dist-windows/FEnigma-0.1.0.msi (gitignored).

Not yet installed/launched on a real Windows machine to confirm the
app actually runs -- packaging succeeding isn't the same claim as the
app working once installed, per this repo's own README note. Logged
as the next thing to check, along with light.exe's own ~15-18min
runtime now that there's a clean build to measure it against.

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

TODO.md

@@ -306,7 +306,7 @@ each confirmed live against the real VM, not just read off a diff:
         (process was active, 343MB working set, not hung on a dialog),
         not a real bug: retried with a 40-minute budget and it finished
         `light.exe` itself in a few more minutes.
-  - [ ] ...and then failed for a REAL reason right at the very end:
+  - [x] ...and then failed for a REAL reason right at the very end:
         `light.exe`'s ICE80 validation rejected essentially every
         harvested file -- "This 32BitComponent ... uses 64BitDirectory".
         `product.wxs`'s own `INSTALLFOLDER` is correctly under
@@ -325,14 +325,24 @@ each confirmed live against the real VM, not just read off a diff:
         (`product.wxs`) or harvested (`files.wxs`) alike, the standard
         WiX v3 way to make a whole package consistently 64-bit. Kept the
         harmless-but-insufficient `-platform x64` on `heat.exe` too.
-        Applied, NOT YET re-verified live (this session's VM time is
-        long since past reasonable for one sitting -- next run should
-        confirm a real `.msi`, but treat that as still unconfirmed until
-        it actually happens).
-        Once confirmed, revisit the still-slow `light.exe` step itself
-        (the ~1GB+ bulk-copied mingw64 dist tree, see README's own "not
-        lean" note) as a separate, real perf follow-up -- 40 minutes for
-        one MSI link is a lot, even once it stops failing outright.
+
+        **CONFIRMED live**, third attempt: `build_errorlevel=0`,
+        `BUILD_DONE`, and a real 958MB `FEnigma-0.1.0.msi` written to
+        `Z:\dist` -- the first ever fully successful build this pipeline
+        has produced. Copied to `dist-windows/FEnigma-0.1.0.msi` in the
+        repo root (gitignored, same as `build_windows.sh` itself would
+        do). NOT yet installed/launched on a real Windows machine to
+        confirm the app actually runs (see the "Not tested against a
+        real GTK4/libadwaita Windows install at all" line in this repo's
+        own `packaging/windows/README.md` -- still true, packaging
+        succeeding is not the same claim as the app working once
+        installed).
+
+        Follow-up, now that a clean build exists to measure against:
+        `light.exe` alone took ~15-18 minutes even with ICE80 fixed --
+        revisit the ~1GB+ bulk-copied mingw64 dist tree (README's own
+        "not lean" note) as a real perf issue, not just a packaging-
+        correctness one.
 
 ## OCR: new fire-support-request grammar gaps (from real user-pasted messages)