fix(ci): unblock the three failing native lifecycle legs

Works #11 — the "Native Package Lifecycle" half.

Three of the four matrix legs failed, each for its own reason, and none for anything the lifecycle actually exercises. Linux was green throughout.

Run 32215619783:

Windows: WiX never installed

The windows-2025 image already ships WiX v3.14.1.20250415, and the workflow asked choco for --version=3.14.1 — a downgrade against it:

A newer version of wixtoolset (v3.14.1.20250415) is already installed.
 Use --allow-downgrade or --force to attempt to install older versions.
Chocolatey installed 0/1 packages. 1 packages failed.

So the step died before it ever looked for the toolset it needed. It now probes first and installs only when WiX is genuinely absent.

Windows: the evidence upload read a directory nothing writes

The matrix carried two fields, name and report, and on Windows they disagreed. CRAFT_EVIDENCE_LABEL is matrix.name, so the script wrote artifacts/native-lifecycle/windows-x64/ — while the upload read .../win32-x64/:

##[error]No files were found with the provided path: artifacts/native-lifecycle/win32-x64/report.json

That would have failed the leg even after the WiX fix. Collapsed to the one field so they cannot drift again; the other three legs had identical values, so nothing else changes.

Windows: the MSI was being compiled 32-bit

candle.exe defaults to -arch x86, and WiX v3 deprecated the Package/@Platform attribute that renderWixSource sets. So an x64 payload was wrapped in a 32-bit installer whose one component declares Win64="yes" and installs under ProgramFiles64Folder. ICE80 exists to catch exactly that contradiction — and light -sval turns validation off, so nothing reported it. The architecture is now passed explicitly, extracted as candleArguments() and unit-tested in the same style as codesignArguments / notarytoolArguments next to it.

This is the one change here I could not run: no Windows box. It follows the WiX v3 docs (Package/@Platform deprecated in favour of candle -arch), and it matches the "Windows x64 MSI platform/install-root correction" #11 refers to downstream. The leg has never run past setup, so this cannot regress anything.

macOS: EISDIR

sha256() was called on every packaged artifact, and one of them is the .app bundle — a directory. Both macOS legs died there, after every packaging, install, update and rollback step had already passed.

Bundles now hash as a tree: each file's path, then its mode bit or symlink target, then its contents, in sorted order. Verified against a real fixture bundle:

stable across two reads:               true f5d5a535570ab21343...
changes when a file is added:          true
changes when a file moves:             true
sees a symlink:                        true
distinguishes symlink targets:         true
back to the original after cleanup:    true

report.json records sha256Kind: "file" | "tree" per artifact, since the two digests are not comparable. Additive — no consumer has ever seen a digest for a directory artifact, because it always threw.

Hashing also ran after the try/catch, so anything it threw escaped main before report.json was written — losing the record of the entire run and failing the evidence upload for good measure. Hash failures are now recorded per artifact and still fail the job.

Verification

• bun scripts/native-lifecycle.ts end to end locally on darwin-arm64: "status": "passed", six artifacts, the two .app bundles hashing as tree and the dmg/pkg as file
• bun test — 468 pass, 0 fail (16 in package.test.ts, including the new candleArguments one)
• tsc --noEmit clean, pickier clean on all four changed files

Not in this PR

• The Releaser half of #11. Its Linux leg failed on sub-compilation of mingw-w64 crt2.o failed, which #21 already fixed; its macOS leg fails the deliberate Require macOS release credentials gate, which stays. Until the seven APPLE_* secrets are set, #11's release acceptance criteria cannot be met — and because npm is needs: [pantry], nothing publishes at all in the meantime. That is the gate working as designed, so I have left it alone.
• The pantry warning package bun.sh@1.3.14 not found in registry / pantry workspace install failed. It appears on every leg including the green one; the action's own SDK path installs bun successfully either side of it, so it is noise from upstream rather than a blocker here.