fix(windows): make Windows ARM64 build start and package correctly

[aequivalent2]

Summary

Two fixes needed for a working win32-arm64 build/release, on top of the packaging groundwork
from #1725:

1. App crashes immediately on launch on arm64. getWindowsRegistryItem()
   (src/app/windows.utils.ts) threw unconditionally on any non-x64 architecture, before ever
   attempting to load the native @vscode/windows-registry module. Since
   readManagedConfig() (src/app/managedConfig.service.ts) is called at module scope in
   AppConfig.ts, i.e. on every app start, this throw is never caught: Error: getWindowsRegistryItem is only available on x64

2. MSI installer would be mislabeled as x64 even when packaging arm64.
   MakerWix in forge.config.js hardcoded arch: 'x64'. electron-wix-msi's MSICreator
   does not auto-detect architecture (this.arch = options.arch || 'x86') - it just embeds
   whatever string it's given as the WiX Platform attribute (and derives
   ProgramFiles64Folder vs ProgramFilesFolder from it). The arm64-not-supported comment
   predates electron-wix-msi 5.1.3 (already the resolved version here), which added arm64
   as a valid Platform value via WiX Toolset >=3.14's candle.exe - confirmed working by
   community testing in build: add scripts for Windows ARM64 build #1725.

Changes

• Resolve the native Registry module path per process.arch instead of a hardcoded
  win32-x64 path; treat a missing prebuild for the current architecture as a recoverable
  error (return undefined) instead of throwing.
• Use the existing TARGET_ARCH variable (already used for Squirrel installer filenames) for
  MakerWix's arch option instead of a hardcoded 'x64'.

Both changes are no-ops for existing x64 packaging/behavior.

Testing

• Applied and verified both patches against a fresh clone of main (git am, no conflicts).
• Verified windows.utils.ts change with esbuild (syntax/bundle check).
• Verified forge.config.js change with node --check.
• Verified electron-wix-msi@5.1.3 (resolved via @electron-forge/maker-wix@7.11.1) accepts
  arm64 as options.arch by reading MSICreator's source directly.

Related

• build: add scripts for Windows ARM64 build #1725 (Windows ARM64 packaging support)

[ShGKme]

Thank you and sorry we missed the arm64. One day we'll have a Windows arm64 device for testing =D

Instead of ignoring arm64, let's actually add support for it.
I'm preparing a new release of the package with arm64 support.

You can test it locally with:

npm i github:nextcloud-deps/vscode-windows-registry#fix/build-arm64

If you have any errors on install, just ignore scripts:

npm i --ignore-scripts github:nextcloud-deps/vscode-windows-registry#fix/build-arm64 

[ShGKme]

The comment isn't entirely true. WiX Toolset >=3.14's candle.exe indeed claims to support arm64.

However, electron-wix-msi@5.1.3 doesn't. It is documented as

Values can be either x86 or x64

https://github.com/electron-userland/electron-wix-msi/blob/v5.1.3/README.md?plain=1#L150-L151

And the source code checks for this property like it is either one or another.

For example: https://github.com/electron-userland/electron-wix-msi/blob/f62348b06b8dd855a13f276782d862f3acc16bd2/src/creator.ts#L410

[ShGKme]

Probably, we can use arm64 here. But I'm unsure if it is needed. This is only the installer arch, not the installed app, isn't it?

[ShGKme]

Do you have any problems with x64 installer?

[aequivalent2]

electron-userland/electron-wix-msi#150

This issue states that, while not officially supported, it does work.

[ShGKme]

Asking just in case. If this PR is AI Assisted, please, add Assisted-by: AGENT_NAME:MODEL_VERSION to the commit description.

Details: https://github.com/nextcloud/server/blob/master/.github/CONTRIBUTING.md#ai-assisted-contributions

[aequivalent2]

Ive added a few things

[aequivalent2]

Is there anything what has to be done now?