Extension host pins one CPU core for hours, log-silent - measured as a native file-watcher busy-loop (~245k other-I/O ops/s, 0 reads/s) on Windows

## Summary

VS Code extension hosts in windows with active Claude Code sessions recurrently pin one P-core (95-100% of a core) for hours. The extension's own log is silent during the burn (heartbeats only). On a thin laptop this presents as an overheating machine at "6-14% CPU" - a single pinned core boosting to ~5 GHz drives an i9-12900HK to TjMax while Task Manager looks idle. Three separate incidents in one day, in three different windows (two different Claude accounts/config dirs, both OneDrive-synced and purely local workspaces).

## Environment

- VS Code 1.134.0 (110a328ea54), x64
- anthropic.claude-code 2.1.240
- Windows 11 Pro build 26200
- i9-12900HK (20 threads), 64 GB
- Two Claude config dirs: `~/.claude` and a second account dir whose `skills/agents/commands/hooks` subdirs are NTFS junctions into `~/.claude`
- Multiple VS Code windows open concurrently, each with the extension active

## Measured evidence

Killing the spinning host restored the machine instantly both times it was tried (package power 36->16 W and 29->10 W within seconds), so the host process is conclusively the workload.

On the third incident I sampled the spinning host's Win32 I/O counters over 10 s while it sat at ~98% of one core:

```
reads/s = 0 writes/s = 0.9 other/s = 245,552
```

~245k "other" I/O operations per second with essentially zero reads/writes is the signature of a native directory-watch busy-loop (`ReadDirectoryChangesW` layer), not JS work, GC, or a rescan loop - a JS-level spin shows near-zero I/O. This matches the Windows watched-directory busy-loop documented in nodejs/node#61398 (libuv fix merged 2026-03-31). Question for the team: does the runtime bundled with current VS Code / the extension carry that libuv fix?

## Additional context

- During the sustained burn the extension log emits only once-per-minute heartbeats - no errors, no activity - so the loop is below the extension's logging.
- Environment factor that may matter: the junctioned second config dir means the same physical `~/.claude/skills` tree is watchable via two logical paths. Bulk rewrites of that tree (a config-deploy hook we have since fixed on our side) produced 300-600 `Detected skill change` events per rewrite in EVERY open window, each followed by multiple full `Loaded N unique skills` reload cycles - each file appearing 3-4x per storm suggests duplicate watch registrations across the junction paths.
- However, the third spin began ~35 minutes after the last rewrite, with zero fresh file changes (mtimes verified) - so the storm is at most a trigger/amplifier; the loop latches and persists on its own.
- Incidents occurred in both an OneDrive-synced workspace and a purely local git-repo workspace; the common factor is an active Claude Code session in the window.
- Possibly related open reports: #80767, #19393, #22509.

## What I can provide

A hardware/process watchdog now auto-captures the I/O discriminator on every recurrence, and I can capture an extension-host CPU profile and/or ETW trace on the next incident if useful. Happy to run diagnostics builds or verbose logging.

Start by checking the runtime bundled with VS Code and the extension against the libuv fix cited in nodejs/node#61398. Reproduce the sustained CPU and I/O behavior, using the available CPU profile or ETW trace if possible. Done means identifying the watcher-loop cause and verifying that the extension host no longer pins a core during the reported configuration and file-change conditions.

Written by the indexing model from the issue text.