Correct the ICE80 fix: -arch x64 on candle.exe, not heat.exe -platform

The previous fix (heat.exe -platform x64) was wrong -- re-verified
live with the corrected build.bat confirmed actually deployed to the
VM (ruling out a stale-copy repeat of the earlier watcher bug),
identical ICE80 "32BitComponent uses 64BitDirectory" failures on every
single harvested component. WiX v3's heat.exe -platform flag only
affects registry-key harvesting, it never stamps Win64="yes" on
components.

Real fix: -arch x64 on candle.exe, the compile step, not the harvest
step -- sets the default Win64/Platform for every component compiled
from either source file (hand-authored product.wxs or harvested
files.wxs), the standard WiX v3 way to make a whole package
consistently 64-bit. Kept the harmless-but-insufficient heat.exe flag
too.

Not yet re-verified live -- next run should confirm a real .msi.

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

TODO.md

@@ -309,16 +309,26 @@ each confirmed live against the real VM, not just read off a diff:
   - [ ] ...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".
-        `heat.exe`'s harvest command had no `-platform x64`, so every
-        component it generated defaulted to 32-bit, while
         `product.wxs`'s own `INSTALLFOLDER` is correctly under
         `ProgramFiles64Folder` (a 64-bit mingw64 toolchain is what's
-        actually being packaged) -- a real, on-disk mismatch, not a
-        transient VM issue. Fixed: added `-platform x64` to `build.bat`'s
-        `heat.exe` invocation. NOT YET re-verified against a live build
-        (found right as this session's VM time/cycles were already
-        heavily spent -- next run should get all the way to a real
-        `.msi`, but that's still a claim, not yet a confirmed result).
+        actually being packaged), but nothing was making the components
+        agree -- a real, on-disk mismatch, not a transient VM issue.
+        First fix attempt (`-platform x64` on `heat.exe`'s harvest) was
+        WRONG -- re-verified live, identical ICE80 failures afterward
+        (confirmed the corrected `build.bat` had actually reached the VM
+        this time, ruling out a stale-copy repeat of the earlier watcher
+        bug). WiX v3's `heat.exe -platform` only affects registry-key
+        harvesting, it never stamps `Win64="yes"` on components. Real
+        fix: `-arch x64` on `candle.exe` (the COMPILE step, not the
+        harvest step) -- sets the default Win64/Platform for every
+        component compiled from either source file, hand-authored
+        (`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