fix(cua-driver): make install.ps1 survive the piped invocation it documents

[r33drichards]

install.ps1 documents itself as an irm ... | iex install, and that invocation has been failing outright:

The attribute cannot be added because variable Channel with value  would no longer be valid.

Cause

Piped into Invoke-Expression, a param() block is not a parameter block — it becomes a set of attributed variable declarations. [string]$Channel is therefore initialised to '', and its own [ValidateSet("stable", "nightly")] rejects that default before the body ever runs. The parameter has no default in the set, so the failure is unconditional: it happens for every iex caller, whether or not they pass -Channel.

Run as a real script file the same code is fine, because an unbound parameter is never assigned and validation never fires. That asymmetry is why it survived review.

Fix

Drop the attribute and validate at the point of use, keeping the same accepted values and the same wording as the saved-channel check immediately below it.

Verification

All against mcr.microsoft.com/powershell with the real script, not a reduction:

• Bug reproduced verbatim. Piping the unmodified install.ps1 into Invoke-Expression gives exactly the error above.
• Fix clears it. The patched script proceeds past argument handling into real work — with network disabled it now reaches a socket error against cua.ai:443, where before it died at the param block immediately.
• Guard verified in isolation. Driving Resolve-SelectedChannel directly: nightly → nightly, stable → stable, bogus → invalid -Channel 'bogus'; expected stable or nightly. Case-insensitivity is unchanged, since both -notin and ValidateSet are case-insensitive.

Not verified, and worth a reviewer's attention: I could not run the whole script through on Windows — on Linux it stops on Windows-only environment assumptions well before channel resolution — so the end-to-end install is unproven from here, as is the image build below.

Why it matters beyond the one-liner

The Windows workspace image installs the driver by piping this script into Invoke-Expression, so its build fails at the install cua-driver step. That blocks rebuilding the Windows image at all, which in turn blocks anything that needs a newer driver in the image — including #3132, whose tool-listing fix cannot reach users until the image is rebuilt.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

[r33drichards]

Update on verification, now that CI has run — with one thing a green check does not show.

installer-compatibility / windows-latest passes for both v0.19.2 and v0.19.3. That is real Windows coverage and it confirms this change does not regress normal use: my edit removed a parameter attribute, and those jobs exercise -Channel handling on a real Windows runner.

But those jobs invoke the script as a file — & ./libs/cua-driver/scripts/install.ps1 at line 139 of the workflow — not via irm ... | iex. As a script file an unbound parameter is never assigned and the ValidateSet never fires, which is exactly why this bug could ship green. So the passing Windows jobs verify the path that was already working, not the path this PR fixes.

The iex path remains covered only by what I ran locally under mcr.microsoft.com/powershell: the unmodified script reproduces the build error verbatim, and the patched script proceeds past argument handling into real work.

That leaves a genuine gap: the documented install invocation is not tested anywhere in CI, on any platform. The cheapest close is to switch one matrix entry from the file invocation to iex, so the form the README tells users to run is the form that gets exercised. Happy to do that here or separately — flagging rather than expanding this PR unilaterally.