Setup and marker fixes: correct ARP entry, clear the entry a ZIP install invalidates, refresh the marker on update

[Sev7eNup]

The two consequences of Inno's {app} not following the answer file's installPath — the remaining open point from the CM1 freeze test. Both verified on the lab server.

Apps & Features named the wrong directory

/ANSWERFILE skips the directory page, so {app} keeps DefaultDirName while the adapter installs to installPath. Inno fills InstallLocation with {app}, so the entry pointed at a directory holding the uninstaller and nothing else.

Measured on a lab install to C:\Program Files\NodePilotC:

	before	after
ARP InstallLocation	C:\Program Files\NodePilot\	C:\Program Files\NodePilotC\
marker InstallPath	C:\Program Files\NodePilotC	unchanged

ssPostInstall corrects it from the installation marker — the same source the uninstaller reads. Best-effort by construction: an exception there does not change the exit code (as the [Files] note already records), so a failed write just leaves Inno's own value, which is today's behaviour.

A ZIP install over a setup installation left a dead entry

The GUI setup keeps unins000.exe inside the install directory. Install-NodePilot.ps1 empties that directory, so the entry pointing at it survives with no uninstaller behind it — Windows can then neither run nor clear it. This is exactly how the lab machine came to carry two dead entries at the start of the freeze test.

Sparing the uninstaller is not available. Assert-NodePilotExtractedFiles requires the install directory to hold exactly the signed artifact and nothing else — that check is what stops a binary being swapped before the service executes it. The first attempt at this fix spared unins* and deploy\ and broke it on the first live run:

Extracted artifact file count does not match the signed ZIP contents.

So the entry that has just become dead is removed instead, and only under both conditions:

• its UninstallString points into the directory just emptied, and
• that target really no longer exists.

An entry that still works, or one belonging elsewhere, is left alone. Without both conditions this would quietly become "delete every uninstall entry on the machine", so both are pinned by contract tests.

Known limitation, unchanged

The installation marker is a single key (HKLM\SOFTWARE\NodePilot\Server). A host running more than one instance keeps only the most recently installed one, and uninstalling any instance clears it for all — observed again in this round. The uninstaller falls back to the old defaults when it is absent. Fixing that means keying the marker per service name, which is a larger change than this one.

Verified live on CM1

• Install to a non-default installPath → ARP InstallLocation names the product directory.
• ZIP installer run over the GUI installation in the same directory → exit 0, service healthy (/healthz/ready 200), all 174 workflows intact, and the dead entry gone instead of orphaned.
• The second instance was uninstalled and the lab left on a single healthy installation.

Ran: Test-DeploymentTemplates.ps1, Test-SetupAdapter.ps1. No product code outside deploy/ is touched, so the backend suites are unaffected and covered by CI.

[Sev7eNup]

Added the remaining marker point to this branch (db5135f).

Update-NodePilot.ps1 now refreshes the installation marker. Only the installer wrote HKLM\SOFTWARE\NodePilot\Server, so its Version kept naming the last install and every script-driven update was invisible in it — including on the setup wizard's own mode page, which reads exactly that value to tell the operator what is already installed.

Verified on CM1:

	marker	binary
before the update	1.2.7-rc2	1.2.6+ef24d76
after updating to the 1.2.5 artifact	1.2.5	1.2.5+a8565ed

Previously the marker column would have stayed at 1.2.7-rc2.

Version only — path, service name, provider and port are not changed by an update and are already correct. Guarded on InstallPath: the marker is a single machine-wide key, so on a host with a second instance it may describe a different installation, and stamping this update's version onto that one is worse than leaving it stale. Both the refresh and that guard are pinned by contract tests.