vsce-testing: orphaned `.drive-udd-*` dirs accumulate when a run never reaches teardown

Summary

Start-VSCodeDrive mints a uniquely-named user-data dir per launch, and Stop-VSCodeDrive deletes it. The happy path is correct. But when a run never reaches teardown — agent interruption, crash, killed session, an exception between start and stop — the dir is orphaned and nothing ever reclaims it.

Found while reclaiming disk space on a dev machine: 21 orphaned .drive-udd-* dirs, 10–30 days old, in .github/skills/vsce-testing/.

Evidence

scripts/vscode-drive.psm1:

# L166 - new dir per launch
$udd = Join-Path $harness (".drive-udd-" + [guid]::NewGuid().ToString('N').Substring(0, 8))

# L516 - cleaned ONLY via Stop-VSCodeDrive
Remove-Item $Ctx.Udd -Recurse -Force -ErrorAction SilentlyContinue

There is no sweep at start, and no try/finally guaranteeing teardown, so the cleanup is reachable only on the path that completes normally.

Impact

Low severity, unbounded growth. The 21 orphans totalled ~50 MB, but two of them were ~22 MB each — size depends on how far the VS Code instance got before dying, so a run that loaded the C# extension leaves a much bigger dir. On a machine running this skill regularly it grows without limit, and it is invisible because the dirs are gitignored (.gitignore:4).

Suggested fix

Defensive sweep in Start-VSCodeDrive: before creating the new dir, remove any existing .drive-udd-* in the harness whose leaf name does not appear in the command line of a live process. The liveness check already exists — Get-VSCodeWindow (L218) and Stop-VSCodeDrive (L513) both match CommandLine against the udd leaf, so the same predicate can be reused. That makes cleanup self-healing without risking a dir belonging to a concurrently running instance.

Worth pairing with a try/finally around the drive lifecycle so normal exceptions still hit teardown.

Notes

• Pre-existing on main; unrelated to any open PR.
• The .drive-extensions/ dir is a different case and should not be swept — it is an intentional cross-run cache of installed extensions.

Start in scripts/vscode-drive.psm1 at Start-VSCodeDrive, then compare the liveness matching in Get-VSCodeWindow and Stop-VSCodeDrive. Verify the cleanup targets only orphaned .drive-udd-* directories, preserves directories belonging to live processes, and never sweeps .drive-extensions/; also review the drive lifecycle for the suggested try/finally coverage.