install-tools.ps1: node registry always targets OpenJS.NodeJS.LTS, silently mismatched when the Current channel is installed instead

[ptr727]

Summary

host-setup/windows/install-tools.ps1's $TOOLS registry hardcodes the node entry to the winget package OpenJS.NodeJS.LTS. On a host where OpenJS.NodeJS (the Current/non-LTS channel) is installed instead, winget list --id OpenJS.NodeJS.LTS --exact still returns a match — winget's list --id appears to match against the installed entry by name/publisher rather than by confirming that id is what was installed, so the mismatch is invisible in the report.

Evidence, from a Windows host

• Actual installed package, per winget list --name "Node.js" (no id filter): OpenJS.NodeJS 26.7.0.
• winget list --id OpenJS.NodeJS.LTS --exact --source winget also matches it, and reports the same row under the OpenJS.NodeJS.LTS id.
• winget show --id OpenJS.NodeJS.LTS --exact (a strict manifest lookup, unlike list) reports Version: 24.19.0 — the current LTS channel release, not the Current channel's.
• Net effect in install-tools.ps1 -Report: node 26.7.0 24.19.0 ... current — the row reads "current" only because 26.7.0 ≥ 24.19.0 by the script's own version compare, not because the tool verified the right package is what's being compared.

Why this matters

The script only acts (winget upgrade --id OpenJS.NodeJS.LTS --exact ...) when its status resolves to outdated. Today that never fires on a host like this one, purely by version-compare coincidence. If the Current channel's version ever reads lower than what the LTS manifest reports as available, -Upgrade/-Install would run winget upgrade --id OpenJS.NodeJS.LTS --exact against a host that has OpenJS.NodeJS installed, not OpenJS.NodeJS.LTS. What winget does with that mismatch (no-op, error, or installing the LTS package fresh alongside/instead of the Current one) isn't verified here, and none of the likely outcomes are the one the caller wants.

Suggested direction

Have the node entry (or Get-ToolState) account for both OpenJS.NodeJS and OpenJS.NodeJS.LTS, detecting whichever channel is actually installed and reading/acting on that id, rather than assuming LTS. Leaving the exact shape as a decision for whoever picks this up.

Host

Windows 11 Pro 10.0.26200, PowerShell 7.6.4, winget (App Installer), unelevated.

[ptr727]

Fixed in #696 (squash-merged to develop as c8a50a4), verified live on the reporting host.

Resolved node's real installed winget package id via a Family-scoped catalog search matched against the already-correct installed version, instead of assuming OpenJS.NodeJS.LTS. That resolved id now flows through status, notes, the report, and every install/upgrade/remove action. Also closed two follow-on gaps a multi-agent review turned up on the same PR: a nondeterministic pick when two sibling ids briefly share a version, and a doomed retry loop for a host pinned to a legacy/capped major that can never itself clear the version floor (-Upgrade/-Reinstall now point such a host at installing the tool's default instead).