Use executable icon for MSI Start Menu shortcut

[PatrickSys]

Closes #135

After the update, the pin still opened Strand, but its saved icon path pointed to a missing Windows Installer file.

Tauri's MSI template sets ProductIcon on the Start Menu shortcut. This removes that setting so Windows can use the icon from strand.exe.

Maintenance cost: Tauri has no per-shortcut icon setting, so this replaces its full WiX template with a Strand-owned copy. That copy will need to be synced when Tauri changes its template.

Still unverified: The exact update path and behavior during a Windows MSI upgrade with an existing pin. An old pin may need to be pinned again.

[danielss-dev]

This is the only intentional behavioral change vs tauri-bundler v2.11.2 (verified). Removing Icon="ProductIcon" is the right lever for new Start Menu shortcuts so Windows resolves the icon from strand.exe instead of the installer ProductIcon cache.

Blocker for merge is proof, not this line: #135 is specifically a taskbar pin after an in-app MSI upgrade. Please confirm (or document clearly if still unknown):

1. Does an MSI major upgrade rewrite / recreate this Start Menu shortcut so existing installs pick up the EXE icon?
2. Do already-pinned taskbar shortcuts under %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar keep the old ProductIcon path until the user re-pins? If so, this PR prevents recurrence for new pins but does not heal pins that already broke — call that out in the issue/PR body.

[danielss-dev]

Thanks for the careful diagnosis on #135 and for owning the WiX fork cost up front.

What looks good

• Intentional delta vs upstream tauri-bundler v2.11.2 is tiny and correct: drop Icon="ProductIcon" on ApplicationStartMenuShortcut, keep ARPPRODUCTICON / ProductIcon for Add/Remove Programs, keep AppUserModelID.
• Sync comment + scripts/check-release-security.mjs guards make the fork less likely to silently regress.

Why I'm not merging yet

Leaving this as draft / not merging until the items below are addressed.

1. Proof gap for the reported bug (blocker)

#135 is: after an in-app update, an existing taskbar pin shows a blank icon while still launching Strand. The PR body says the MSI upgrade / existing-pin path is still unverified.

Please add Windows evidence (screenshots or a short write-up of what you ran) for at least one of:

• Preferred: install an older MSI → pin to taskbar → install/updater-upgrade to a build from this branch → pin icon still resolves (or document that re-pin is required and show Start Menu / fresh pin are correct).
• Minimum: build MSI from this branch → fresh install → Start Menu shortcut icon comes from strand.exe (Icon location / properties), and a new taskbar pin does too.

Without that, we risk merging a large template fork that only helps future shortcuts while leaving the reported failure mode unproven.

2. CI (blocker)

No checks are reported on 7d85df8 (mergeable_state=unstable, draft). Please mark ready for review (or push a no-op) so the normal PR checks run green before merge. I know Linux CI won't exercise WiX; we still want the usual Frontend/Rust (and security script) gates, including the new check-release-security.mjs assertions.

3. Maintenance expectation (non-blocking, please acknowledge)

Forking all of main.wxs is the right hammer given Tauri's lack of a per-shortcut icon knob — please keep the header comment's tauri-bundler version accurate when CLI bumps, and re-diff upstream on Tauri upgrades. No code change needed for this comment; just confirm you'll treat that as the sync ritual.

Decision

Request changes — do not merge until (1) upgrade/pin proof or an explicit “existing pins need re-pin; this prevents recurrence” statement backed by a fresh-install/pin check, and (2) CI green. Happy to re-review quickly after that.