Guard against PowerShell `$home` variable footgun causing user profile mutation/deletion

## Summary

PowerShell's variable names are case-insensitive, so a seemingly local variable named `$home` resolves to the built-in read-only `$HOME` variable. When a generated or agent-authored script intends to use `$home` as a scratch path and then runs cleanup such as `Remove-Item -Recurse -Force $home`, PowerShell can target the user's real profile directory instead of the intended temporary directory.

I've now seen this pattern multiple times in agent-generated PowerShell. In one case during Copilot CLI hook testing, this command shape attempted to remove content from the user profile before the process was stopped:

```powershell
$home = 'C:\Users\name\.copilot\session-state\...\files\copilot-home-hooks'
if (Test-Path $home) { Remove-Item -Recurse -Force $home }
```

Because `$HOME` is read-only, assignment failed, but subsequent references still pointed at the real home directory. That creates a high-risk corrupted-profile failure mode.

## Why this matters

Copilot CLI frequently generates PowerShell for Windows users. `$home` is a natural variable name for directories like app home, tool home, temp home, or Copilot home. In PowerShell this is a dangerous footgun because it aliases the built-in `$HOME` variable by case-insensitive lookup.

## Suggested mitigations

- Add a Copilot CLI/system instruction for PowerShell generation: never use `$home` as a user-defined variable; use names like `$userProfile`, `$homeDir`, `$copilotHomePath`, or `$targetRoot` instead.
- Add a safety rule or lint-like guard before destructive PowerShell commands when the target variable is `$home`/`$HOME`.
- Consider warning or requiring confirmation when generated PowerShell combines `$home` with destructive recursive operations such as `Remove-Item -Recurse`.

This is especially important for autonomous/remote sessions where a user may not see the exact command before damage occurs.