Stricter download verification for agent shims in SSH - #6844

This fails on Windows CI (task test-exp-ssh (windows), run 36123224218). Every subtest that extracts an archive errors with tar: Cannot connect to C: resolve failed.

ensureBinary shells out to the system tar with an absolute temp path (agentshim.go:439). CI steps use shell: bash, so on Windows that's Git's GNU tar, which parses C:\... as host:path (a remote archive). The shim only ever runs on the Linux driver, so either skip this test on Windows or avoid handing tar a drive-letter path.

If uv is already on PATH (shipped by the image or installed by the user), this branch is skipped, so uvToolBinDirAbsolute never gets on PATH. But ucode is always installed into it (line 376), so launchAgent fails with "the Unity Gateway CLI was not found on PATH after setup". The failure is permanent: on every later launch toolchainReady() is false, uv tool install finds ucode already installed, and the launch fails again.

Before this PR, ~/.local/bin (uv's default tool bin dir) was prepended on every launch, so this case worked.

Even when uv is missing, PATH is now only rebuilt through these install branches. So every relaunch takes the setup lock and prints "Installing uv..." / "Installing npm..." without downloading anything. I'd prepend deps/uv, uvToolBinDir and deps/node/bin unconditionally in bootstrapAndLaunchAgent, as before.

Repro (fails on this PR's head with exec: "ucode": executable file not found in $PATH):

func TestUvOnPathUcodeReachable(t *testing.T) {
	home, fakeBin := t.TempDir(), t.TempDir()
	writeScript := func(name, body string) {
		require.NoError(t, os.WriteFile(filepath.Join(fakeBin, name), []byte("#!/bin/sh\n"+body+"\n"), 0o755))
	}
	// fake uv: `uv tool install` drops ucode into $UV_TOOL_BIN_DIR, as real uv does
	writeScript("uv", `mkdir -p "$UV_TOOL_BIN_DIR" && printf '#!/bin/sh\n' > "$UV_TOOL_BIN_DIR/ucode" && chmod +x "$UV_TOOL_BIN_DIR/ucode"`)
	writeScript("npm", "exit 0")
	t.Setenv("PATH", fakeBin+":/usr/bin:/bin")

	require.NoError(t, ensureToolchain(cmdio.MockDiscard(t.Context()), home))
	_, err := exec.LookPath("ucode")
	assert.NoError(t, err)
}

ah good catch, I was testing the no uv case heavily since I always tested with uv installed before and missed this 🤦

This used to be return err. Swallowing the error means a cancelled context (Ctrl-C while waiting on a concurrent setup), a failed MkdirAll, or a permission error on the lock file skips installation silently. The user then gets the misleading "the Unity Gateway CLI was not found on PATH after setup" from launchAgent instead of the real cause. This change also looks unrelated to the pinning work.

Repro (on this PR's head, ensureToolchain returns nil):

func TestSetupLockErrorSurfaces(t *testing.T) {
	home := t.TempDir()
	t.Setenv("PATH", "/usr/bin:/bin")
	lock := filepath.Join(home, agentRootDir, setupLockName)
	require.NoError(t, os.MkdirAll(filepath.Dir(lock), 0o755))
	require.NoError(t, os.WriteFile(lock, nil, 0o644)) // held by a concurrent client

	ctx, cancel := context.WithTimeout(cmdio.MockDiscard(t.Context()), 1500*time.Millisecond)
	defer cancel()
	assert.Error(t, ensureToolchain(ctx, home))
}

Yeah this is just bad refactoring 🤦 Had this function returning ([]string, error) before and I must have removed the wrong return