fix(scripts/win-installer): install the version reported in Add/Remove Programs - #27927

Installing a newer Coder release over an older one can leave coder.exe untouched while Add/Remove Programs is updated to the new version. The reporter installed v2.35.3 over v2.34.7 and got ARP 2.35.3.0 alongside coder version reporting v2.34.7+b7d2742.

Root cause

The install section used SetOverwrite ifnewer, which compares file mtimes, while the registry writes a few lines below are unconditional. Coder cuts patch releases for older minor branches after newer minors ship, so the older release routinely carries the newer binary. Read straight out of the two published installers with 7z l:

So upgrading v2.34.7 to v2.35.3 asks NSIS to replace a file that is a day newer than its payload, ifnewer skips it, and the registry still advertises 2.35.3. SetOverwrite on (the NSIS default) restores the invariant that the installer installs what it contains. Downgrades and repair installs over a locally modified binary fail the same way and are fixed by the same change.

Fixes #27088
Fixes #27876
Linear: ENT-137, PLAT-466

Scope

This kills a cause that fires unconditionally: with the shipped artifacts, every v2.34.7 to v2.35.3 upgrade hits it, with no dependence on user action or timing. It does not close the whole symptom class. Two other paths produce the same "ARP disagrees with the CLI" result and are untouched here:

• Locked coder.exe. If the binary is running, Windows cannot replace it. Verified under Wine that the silent installer exits 0 and keeps the old binary both before and after this change, so ARP still ends up advertising a version that is not on disk. Closing it needs AllowSkipFiles off plus error handling around File, or rename-and-replace. That makes silent upgrades fail loudly where they currently no-op, which changes the winget and enterprise silent-deploy contract, and it is the one path this Wine harness cannot validate. It belongs in its own PR with a real Windows test.
• PATH shadowing, unconfirmed. coder version resolves through PATH, and path.nsh only ever appends $INSTDIR\bin, so it never wins over an earlier entry. An older coder.exe from a zip or scoop install ahead of it would report the old version even after a completely successful overwrite. The reporter's screenshot shows the output of coder version, not the command with a full path, so this cannot be ruled out as a contributing factor in their case. If it turns out to be theirs, it is a separate bug and this change will not help them.

Also unchanged: the .0 suffix in ARP. DisplayVersion stays 2.35.3.0, the conventional four-part Windows form that VIProductVersion requires. Shortening it to 2.35.3 is cosmetic: winget already treats 2.35.3.0 and 2.35.3 as equal, ${CODER_VERSION} is 2.36.0-devel+<sha> on non-release builds, and existing SCCM/Intune rules matching 2.x.y.0 would see a split fleet. Not worth coupling to a correctness fix.

Verification

Real NSIS installers built by the unmodified scripts/build_windows_installer.sh from two trees, run silently under Wine. Payload mtimes are the exact values read out of the released v2.34.7 and v2.35.3 installers above.

# baseline
/tmp/verify/main-wt/scripts/build_windows_installer.sh \
  --version 2.35.3 --output installer-2.35.3-baseline.exe coder-2.35.3.exe
# fixed
/home/coder/coder/scripts/build_windows_installer.sh \
  --version 2.35.3 --output installer-2.35.3-fixed.exe coder-2.35.3.exe

This pull request was created by Coder Agents on behalf of @david-fraley.