fix(installer): give the NSIS hooks the macro names the bundler checks for

[PathGao]

tauri.conf.json points bundle.windows.nsis.installerHooks at hooks.nsi, which
defines NSIS_HOOK_POST_INSTALL and NSIS_HOOK_POST_UNINSTALL. The bundler
guards its call sites with NSIS_HOOK_POSTINSTALL and
NSIS_HOOK_POSTUNINSTALL — no underscore:

installer.nsi @ tauri-cli-v2.9.6   (the version package-lock.json pins)
  617:  !ifmacrodef NSIS_HOOK_PREINSTALL
  709:  !ifmacrodef NSIS_HOOK_POSTINSTALL
  754:  !ifmacrodef NSIS_HOOK_PREUNINSTALL
  862:  !ifmacrodef NSIS_HOOK_POSTUNINSTALL

Same at tauri-cli-v2.0.0 and on dev — the underscored spelling has never
existed. !ifmacrodef is a compile-time conditional, so the mismatch produces no
error and no warning. The file has never run, from b89fc17 (2026-01-12) to
today. Nothing tested it.

Why the macros were not simply renamed

Renaming alone would have activated three behaviours that conflict with the
template. Each was checked against 2.9.6 rather than assumed:

hooks.nsi did	template
create $DESKTOP\Markpad.lnk unconditionally	finish-page checkbox (:386), auto only for silent/passive (:702), and CreateOrUpdateDesktopShortcut returns early on $UpdateMode (:945)	removed
write Applications\Markpad.exe\shell\open\command	not covered	removed — see below
write Open with Markpad under .md\shell, SystemFileAssociations\.md\shell and OpenWithList	APP_ASSOCIATE (:642) writes the verb under the ProgID only	removed — see below
SHChangeNotify(SHCNE_ASSOCCHANGED)	not covered; FileAssociation.nsh ships UPDATEFILEASSOC for it and installer.nsi includes the header but never inserts the macro	kept

Every write in the file was hardcoded HKCU while the template writes through
SHCTX, which follows installMode: "both" — so an all-users install would have
put per-user keys in an elevated user's hive.

The shortcut row is the concrete one: tauri-plugin-updater 2.10.1 passes
/UPDATE, which is precisely why the template skips shortcut creation during an
update. The hook would have recreated a desktop shortcut the user had deleted, on
every auto-update.

Removing rows that never ran changes nothing at runtime; keeping one is the
behaviour change. SHChangeNotify is the only keeper — no registry writes, so the
hive question does not arise, idempotent, and it restores the intended use of a
header the template already includes.

A fix that never shipped

a5fda8e — "Fix markdown preview wrapping and open-with registration",
2026-04-30 — added the Applications\ and OpenWithList registrations to fix a
real report. It went into a file that does not execute, so that fix has never
reached a user, and the open-with gap is probably still open. Reviving it means
converting the hardcoded HKCU to SHCTX and deconflicting a second
Open with Markpad label against the template's own — Windows-only validation, so
it wants its own PR rather than a rider on this one. Flagging rather than dropping.

The guard

scripts/nsisInstallerHooks.test.ts: the configured hook file exists; every
NSIS_HOOK* macro it defines is one of the four the bundler checks; and while
installMode is not currentUser, no hook names a registry hive outright. Against
the file as it stood:

✖ installer hook macros are spelled the way the bundler checks for them
  hooks.nsi defines !macro NSIS_HOOK_POST_INSTALL, which no !ifmacrodef in the
  bundler template matches, so it is never inserted.
  Expected one of: NSIS_HOOK_PREINSTALL, NSIS_HOOK_POSTINSTALL,
  NSIS_HOOK_PREUNINSTALL, NSIS_HOOK_POSTUNINSTALL

✖ installer hooks write through the install-mode hive, not a hardcoded one
  + [ 'HKCU' × 12 ]   - []

The failure mode here was silence; a name check is the only thing that turns it
into a signal. If installerHooks is ever dropped entirely the tests no-op, so the
guard does not stand in the way of retiring the file later.

Two things found while checking, neither fixed here

<ProgID>_backup self-clobbers, in the template. FileAssociation.nsh:70-71
writes .md's current handler into Markdown File_backup unconditionally; on a
reinstall that value is already Markdown File, so the backup overwrites itself,
and APP_UNASSOCIATE then restores .md to a ProgID it deletes in the next line.
The restore is unconditional too, so uninstalling stomps a .md association a
different editor took over afterwards. This is #255/#256 again, in the NSIS path.
A NSIS_HOOK_PREINSTALL alone cannot fix it — it runs before APP_ASSOCIATE — so
it needs a PRE/POST pair, and arguably belongs upstream in FileAssociation.nsh.

The two install paths use different ProgIDs. NSIS writes Markdown File;
setup.rs writes Markpad.File with its own PreviousAssociations subkey. They
can clobber each other's .md default. Relevant to #395.

Verification

npm test        643 / 643
npm run check   0 errors
cargo test      154 / 154
npm audit       0 vulnerabilities

Not verifiable without Windows, and stated as inference rather than
measurement: that the shell actually refreshes on the SHChangeNotify call; that
NSIS compiles the file (there is no NSIS on macOS — the guard is a name check, not
a compile); that NSIS_HOOK_POSTINSTALL now genuinely fires; and whether the
removed Applications\/OpenWithList writes were producing value the template
misses. Worth a look on a real machine before the next release.