fix(msi): forward the Windows installer settings to electron-builder

[takke]

Problem

The MSI target forwards only upgradeCode and perMachine to electron-builder, so every other
Windows installer setting falls back to an electron-builder default. Projects that migrated from
jpackage-based packaging silently lose three behaviours:

Setting	Before (jpackage)	Now (electron-builder MSI)
windows.menuGroup	--win-menu-group → shortcut in a start menu folder	ignored → shortcut lands in the start menu root
installer UI	welcome / progress / finish pages	oneClick defaults to true → installs with no UI at all
after install	nothing	runAfterFinish defaults to true → the app is launched

windows { menuGroup / menu / shortcut / dirChooser } are still read by AbstractJPackageTask,
but TargetFormat.Msi is PackagingBackend.ELECTRON_BUILDER, so nothing in that block reaches
the MSI. There is also no way to set these from a build script, since the electron-builder config
is generated from the DSL inside the task and no user config is merged.

Comparing the MSI tables of the same app built before and after the migration:

before: Shortcut          → dir6433… | ProgramMenuFolder | AppName   (start menu folder)
        InstallUISequence → WelcomeDlg / ProgressDlg / ExitDialog …
after:  Shortcut          → startMenuShortcut | ProgramMenuFolder | AppName   (root)
        InstallUISequence → CostInitialize / ExecuteAction only        (no dialogs)

Fix

Add the remaining CommonWindowsInstallerConfiguration options to MsiSettings and emit them:

windows {
  menuGroup = "MyApp"          // already existed; now honored by the MSI target too
  msi {
    perMachine = false
    oneClick = false           // show the installer wizard
    runAfterFinish = false     // don't launch the app when the installer finishes
  }
}

• Every new option defaults to the electron-builder default, so generated MSIs are unchanged
  unless a project sets one — with one intended exception: windows.menuGroup now acts as the
  default for msi.menuCategory, which is the jpackage-era name for the same concept. Projects
  that declared a menu group get their start menu folder back; projects that never set it are
  unaffected (menuCategory stays unset and nothing is emitted).
• windows.menu / windows.shortcut are deliberately not mapped. Their jpackage defaults
  (false) are the opposite of electron-builder's (true), so mapping them would silently drop
  shortcuts for projects that are happy with today's output. msi.createStartMenuShortcut /
  msi.createDesktopShortcut give explicit control instead.
• Only the MSI target is touched. NsisSettings already exposes oneClick / runAfterFinish /
  createStartMenuShortcut / createDesktopShortcut; it is missing menuCategory and
  shortcutName, which I'm happy to add in a follow-up if you want the two targets aligned.

Verified against electron-builder's MsiTarget.ts:
menuCategory emits <Directory Id="AppProgramMenuDir" Name="ProgramMenuFolder:\<category>\"/>
and anchors startMenuShortcut there (plus a RemoveFolder on uninstall), oneClick === false
adds -ext WixUIExtension to the light args, and runAfterFinish drives isRunAfterFinish in the
WiX template.

Also verified end to end: I published the patched plugin to Maven Local and rebuilt the same app
with menuGroup plus msi { oneClick = false; runAfterFinish = false }. The MSI tables come out
as expected, and installing it behaves like the jpackage-era package again:

	before this PR	after
Shortcut	startMenuShortcut | ProgramMenuFolder	startMenuShortcut | AppProgramMenuDir (folder ProgramMenuFolder\ZonePane)
InstallUISequence	Cost*/ExecuteAction only (no UI)	WelcomeDlg / ProgressDlg / ExitDialog / MaintenanceWelcomeDlg / ResumeDlg
CustomAction	runAfterFinish | 210 | mainExecutable	(absent)
UpgradeCode / per-user	unchanged	unchanged (MSIINSTALLPERUSER=1, same UpgradeCode)

One observable side effect of oneClick = false, inherent to electron-builder's template: the
assisted installer nests the install directory one level deeper
(…\Programs\<app> → …\Programs\<company>\<app>), same as it does for NSIS assisted installs.

Tests

• ElectronBuilderMsiConfigTest (new, 5 cases): defaults are unchanged, each option is forwarded,
  windows.menuGroup is used as the menu category, an explicit msi.menuCategory wins over it,
  and the NSIS target is unaffected.
• MsiSettingsTest: added a defaults case for the new options.

generateWindowsConfig is now internal so the rendered YAML can be asserted, matching
generateLinuxConfig which is already internal for the same reason.

🤖 Generated with Claude Code

[kdroidFilter]

Thank you very much, great! even though I strongly advise using the nsis format and not msi which is deprecated