Decide Windows packaging and auto-update strategy

Problem

The Windows tray currently appears to ship through three different distribution/update paths:

1. Inno Setup installer via installer.iss

   • Release workflow builds OpenClawTray-Setup-x64.exe and OpenClawTray-Setup-arm64.exe.
   • This looks like the friendly/default install path.

2. Portable ZIP artifacts

   • Release workflow builds OpenClawTray-<version>-win-x64.zip and OpenClawTray-<version>-win-arm64.zip.
   • Workflow comments say these ZIPs are for Updatum auto-update.
   • App code configures Updatum like a portable/single-file update flow, not like installer/MSIX update flow.

3. MSIX packages

   • CI/release builds OpenClawTray-<version>-win-x64.msix and OpenClawTray-<version>-win-arm64.msix.
   • Release notes describe MSIX as useful for packaged Windows consent surfaces such as camera/microphone permissions.

That means install/update behavior is ambiguous: a user may install with the .exe, but the in-app updater may consume ZIP assets; MSIX has its own install/update semantics but is not wired into the in-app updater.

Why this matters

We should make a deliberate packaging decision before the Windows tray gets broader distribution:

• avoid users accidentally crossing install technologies during update
• avoid duplicated signing/release complexity if we do not need all formats
• define which package is the supported/default path
• define how camera/microphone/screen permissions should behave for unpackaged vs packaged installs
• make Updatum asset selection explicit and tested

Current evidence

• installer.iss is active in the tag release workflow and builds signed installer .exe assets.
• .github/workflows/ci.yml builds portable ZIPs and comments that they are for Updatum auto-update.
• .github/workflows/ci.yml also builds MSIX packages.
• App.xaml.cs configures UpdatumManager with InstallUpdateSingleFileExecutableName = "OpenClaw.Tray.WinUI" and does not explicitly target installer or MSIX assets.

Decision needed

Pick one of these strategies:

1. Installer-first: EXE installer is the blessed install/update path; configure updater to download/run the installer, and demote ZIP/MSIX as secondary/manual assets.
2. Portable-first: ZIP is the blessed install/update path; keep Inno only for convenience install and document that it transitions to ZIP-based self-update.
3. MSIX-first: MSIX is the blessed install/update path; use MSIX/App Installer update semantics and remove or demote the custom updater/installer.
4. Hybrid, explicitly supported: keep multiple paths, but document and test which updater applies to each installed form.

Proposed acceptance criteria

• Document the supported/default install path in README/release notes.
• Document whether .exe, .zip, and .msix are primary, secondary, or deprecated.
• Make Updatum asset selection explicit, including architecture matching.
• Add/update tests or a release checklist proving the updater downloads the intended asset type.
• Ensure the updater does not accidentally update an MSIX install with ZIP files or an installer install with an incompatible portable layout.
• If multiple install paths remain, document how each one updates.

Start by comparing installer.iss, .github/workflows/ci.yml, and App.xaml.cs to map the installer, ZIP, MSIX, and Updatum paths. Review the README and release notes requirements, then define one supported strategy, document each package's status and architecture matching, and add the requested updater tests or release checklist.