test: keep command tests inside their temp directories on Windows

What does this MR do and why?

Running go test ./... on Windows leaves untracked directories inside the working tree, and writes a real file into the developer's home directory. Three test packages escape their sandbox.

Paths lose their drive prefix

cmdtest.SetupCmdForTest returns an exec that runs the command line through shlex.Split, which treats a backslash as an escape character. A path from t.TempDir() therefore arrives at the command as C:UsersnameAppDataLocalTempTest_...001, which is relative, so the artifacts and skills are written under the package directory:

?? internal/commands/ci/artifact/Users<name>AppDataLocalTempTest_NewCmdRun.../
?? internal/commands/skills/install/Users<name>AppDataLocalTempTestNewCmdInstall.../

Test_NewCmdRun/A regular filename and Test_NewCmdRun/A regular filename in a directory fail as a result, because the file is not at the path the assertion checks.

Passing the value through filepath.ToSlash keeps it absolute. On every other platform it is a no-op.

HOME is not the home directory on Windows

TestNewCmdInstall_GlobalFlag and the --global case of TestSetup_SkillScopeResolution override only HOME, but os.UserHomeDir reads USERPROFILE on Windows. Both resolve to the real home directory instead of the temp one, and TestNewCmdInstall_GlobalFlag creates an actual ~/.agents/skills/glab/SKILL.md on the machine running the suite.

internal/config/config_file_test.go already sets both variables with the comment "Set both HOME (Unix/macOS) and USERPROFILE (Windows) for cross-platform compatibility". These two call sites had not been updated, so this applies the existing convention.

Verification

On Windows, before:

--- FAIL: Test_NewCmdRun/A_regular_filename
--- FAIL: Test_NewCmdRun/A_regular_filename_in_a_directory
--- FAIL: TestNewCmdInstall_GlobalFlag
FAIL internal/commands/orbit/setup

After, internal/commands/skills/install and internal/commands/orbit/setup pass, internal/commands/ci/artifact no longer writes into the working tree, and git status is clean once the suite finishes.

One subtest still fails on Windows and is deliberately left alone: Test_NewCmdRun/symlink can't overwrite cannot create a symbolic link ("A required privilege is not held by the client"). That is a privilege requirement of the platform, not a sandbox problem, and fixing it would mean deciding whether to skip the case on Windows.

Linux behaviour is unchanged: filepath.ToSlash is the identity there, and setting USERPROFILE has no effect on os.UserHomeDir.

Related issues

Closes #8409 (closed)