Windows installer: Finish NSIS to Inno migration?

We're currently still halfway through the migration from NSIS to Inno Setup for the Windows installer:

• Nightlies are already built only with Inno Setup (the "Create Inno Setup installer" step in .github/workflows/nightly.yml).
• The PR-check CI workflow (.github/workflows/ci.yml) still installs the nsis MSYS2 package, even though that job never actually builds an installer.
• cmake/darktable-packaging.cmake still defines a full NSIS/CPack generator branch (explicitly named win64-NSIS-deprecated) alongside the Inno Setup template generation.
• packaging/windows/README.md still only documents the aforementioned NSIS/CPack build path.

As far as I understand, @victoryforce and @kmilos have driven most of the work on this so far: PR #19333 and PR #18718.

Following discussions on pixls.us about testing darktable (nightlies) on Windows (thread), there seem to be a few inconsistencies in when/whether the installer asks for install scope (all users / current user) and install location, depending on which installer is used and on whether Setup finds a previous install to react to.

@victoryforce mentioned in PR #19333 that NSIS should eventually be removed once the Inno Setup installer has been thoroughly tested. Given how much time has passed since then, I'd like to propose we finish the migration. Concretely, this would mean:

1. Update packaging/windows/README.md to document the Inno Setup build path (already used in nightly.yml) instead of the NSIS/CPack one.
2. Remove the NSIS/CPack generator branch from cmake/darktable-packaging.cmake, including the ARM64 special-casing (ZIP fallback) that only exists because NSIS has no native ARM64 support.
3. Drop the now-unused nsis:p MSYS2 package from the PR-check workflow (ci.yml).
4. Before dropping NSIS entirely, it'd be worth ironing out the remaining rough edges in the Inno Setup script that the pixls.us thread surfaced, e.g.:
   • DisableDirPage isn't set explicitly, so it defaults to auto, meaning Setup silently skips the destination-directory page whenever it detects a previous install with a matching AppId. I'd propose setting this to no so the install location is always shown/confirmable.
   • SuffixIfNotRelease() in darktable.iss.in decides between the release and -dev AppId purely by the length of the version string, which could misclassify a dev/nightly build with a short version string as a "release" upgrade.

If there are no objections I'd start working on this @TurboGit @victoryforce @kmilos @wpferguson ?

[disclaimer: I had Claude help me understand the current setup and propose where changes are necessary]