refactor(packaging): push the install-tested Chocolatey package; simplify

[jpicklyk]

Summary

Feature-level /simplify review of the Chocolatey channel. Four reviewers looked at it from different angles (reuse, simplification, efficiency, altitude); this applies the findings that survived deduplication and checking.

Applied

• Push what was tested. The chocolatey job used to re-render and re-pack before pushing, so the package that reached moderation was a rebuild presumed identical to the one chocolatey-verify install-tested. It now downloads chocolatey-verify's .nupkg artifact, whose name is exposed as a workflow_call output so the two can't drift, and pushes that file. The job drops checkout, Node, the render (which downloaded two DMGs it never used) and the pack. Flagged by three of the four reviewers.
• [array]$keys = Get-UninstallRegistryKey …, Chocolatey's own template idiom, replaces @(…) | Where-Object { $_ }. The @() wrapper is what turned $null into a one-element array; this removes the cause rather than filtering after it. Checked locally with stubs returning $null, nothing, one key and two keys: counts 0/0/1/2.
• The COPIES machinery is removed from render-packaging.mjs. The placeholder-free uninstall script is listed with the templates: rendering it is a verbatim copy, and --check already fails on a missing template. The rendered output is byte-identical to main's for all 5 files.
• Invoke-Choco now checks the exit code itself. This replaces six repeated call-then-check pairs, with -ExpectFailure for the tamper step. Labels are unchanged, so CI logs read the same.
• The 409 message no longer claims "likely still pending moderation". Since fix(ci): skip the Chocolatey push only for an approved version #48, a 409 can also mean the version was approved between the feed check and the push.
• Comments: why step 2 uses a fixed sleep rather than polling, and how the literal install path connects to managed_by().

Skipped, with reasons

• Drop the feed pre-check and always push (altitude): that trades a read for a write against a public feed on every re-run, and we've never observed Chocolatey's answer for a push of an approved version. The simplification reviewer independently concluded both guards earn their place.
• Poll instead of the 10 s sleep (efficiency): the wait tests whether the GUI stays up on a headless runner. A poll would pass the instant the process exists, and a later crash would then read as "closed by the installer".
• Pass --icon-commit from the caller (altitude): after actions/checkout, git rev-parse HEAD is github.sha, so the gain is marginal.
• Derive the install path from the ARP entry (altitude): that would weaken the check, since it accepts any location. The literal path is the point.
• A shared version-resolution action (reuse): verify-homebrew.yml is outside this feature, and bash's -e means the two copies don't actually behave differently.
• Seed choco's download cache from the render (efficiency): that would tie the renderer to Chocolatey's cache layout to save about 15 s.

Test plan

• npm run test:scripts: 5/5; render-packaging.mjs --check: clean
• Render output byte-identical to main's renderer, run over the same sources (all 5 files)
• Both workflows parse (js-yaml). The artifact name wiring checks out: version step → job output → workflow_call output → download-artifact in publish-packages. The chocolatey job no longer renders or packs.
• All 9 pwsh blocks and scripts parse. The real Invoke-Choco + Check definitions, pulled from the script's AST and run against a fake choco, give the right verdict for exit 0/1 × -ExpectFailure on/off, with exactly one result object each time
• This PR's Verify Chocolatey package run: the install test against the reworked script and the [array] uninstall
• The artifact handoff in publish-packages only runs on a release or dispatch; the next tagged release exercises it

🤖 Generated with Claude Code