install-k8s.ps1: New-K3dCluster runs `k3d cluster list -o json` unbounded on the main install path

[shujaatTracebloc]

Split out of the #917 review (@LukasWodka, non-blocking there — pre-existing, not touched by that PR).

The call

scripts/install-k8s.ps1 (New-K3dCluster):

$clusterListJson = k3d cluster list -o json 2>&1 | Out-String

Bare, and on the main install path. k3d cluster list talks to the Docker engine, so against a wedged daemon — a half-open \\.\pipe\docker_engine, which is what Docker Desktop leaves behind when it starts and then gives up — this does not fail, it blocks. The install parks there with no console output and nothing to kill it. That is the failure class backend#2849 spent its life removing, and the one this call is still open to.

The fix already exists in the same file

Get-ClusterRunState wraps the identical command in a Start-Job reaped by Wait-JobWithProgress at 15s, and logs a specific line on timeout:

k3d cluster list timed out; cluster run-state indeterminate.

So this is a matter of reusing an established in-file pattern, not designing one. Invoke-DiagnoseCapture (added in #917) is the other option if a plain bounded capture reads better at this site.

Why it was left out of #917

#917 bounded the docker class and every external read in the -Diagnose bundle, and its AST guards cover exactly those two scopes. This call is neither docker nor inside Invoke-DiagnoseBundle, so no guard currently names it — which is precisely why it needs its own ticket rather than being left implicit.

Worth doing with it

Consider widening the AST class guard in scripts/tests/install-k8s.Tests.ps1 from docker to docker|k3d, with an explicit allowlist for anything deliberately left bare. #917 already establishes the pattern:

$native = $ast.FindAll({ param($n) $n -is [CommandAst] }, $true) |
  Where-Object { $_.GetCommandName() -eq "docker" }

Otherwise the next unbounded k3d call lands the same way this one did.

Part of tracebloc/backend#2849.

[shujaatTracebloc]

Scope confirmed and sharpened by @LukasWodka on his #917 approval: it is 14 native kubectl/helm/k3d calls with no timeout of any kind remaining on the main install path, outside the diagnose call-graph closure that #917 bounded — New-K3dCluster (the k3d cluster list -o json this issue names) among them.

Worth restating why none of the existing guards catch these, since that is the actionable part:

• the AST class guard covers docker only;
• the diagnose guard covers the transitive closure reachable from Invoke-DiagnoseBundle only.

So these 14 sit in the gap between the two. Widening the class guard from docker to docker|k3d|kubectl|helm with an explicit allowlist for anything deliberately left bare would close the class rather than the instances — that is the version worth doing here.