[BUG] VS Code extension host 'Not responding' — ping/pong heartbeat timeout during tool execution

Description

The Claude Code VS Code extension intermittently shows "Not responding" in VS Code's extension host. This occurs because the extension thread is blocked during heavy async work (API responses, tool execution, long-running agent operations), causing it to miss VS Code's extension host liveness heartbeat (ping/pong check).

Environment

• VS Code: Latest stable
• OS: macOS (Darwin 25.2.0)
• Claude Code: Latest version
• Model: claude-opus-4-6

Steps to Reproduce

1. Start a Claude Code session in VS Code
2. Execute a complex task that involves multiple sequential tool calls (e.g., file reads, grep searches, bash commands, agent spawning)
3. During tool execution, VS Code flags the extension as "Not responding"
4. The extension recovers once the blocking operation completes

Expected Behavior

The extension should remain responsive to VS Code's heartbeat checks even during heavy async work. The ping/pong loop should stay responsive regardless of API call or tool execution state.

Actual Behavior

VS Code's extension host liveness check fails because the extension thread is blocked waiting on API responses or executing tools. VS Code shows "Not responding" with a red indicator. The extension recovers after the blocking work completes, but the UX is jarring.

Root Cause Analysis

VS Code's extension host has a liveness check that sends periodic pings and expects pongs within a timeout window. When the Claude Code extension performs blocking work on the main extension host thread (waiting for Anthropic API streaming responses, running tool calls, executing bash commands), it misses the heartbeat and VS Code flags it.

Suggested Fix

Run blocking work off the main extension host thread:

• Use a worker thread or child process for API calls and tool execution
• Keep the main extension host thread free to respond to VS Code's ping/pong heartbeat
• The extension already uses child processes for CLI operations — the same pattern could be extended to ensure the extension host thread is never blocked

Related Issues

• #39183 — Similar "Not responding" on WSL2 (WebSocket timeout loop)
• #38994 — All agent panels go gray/unresponsive (possible extension host crash)
• #38580 — Docs missing "Not responding" red spinner after 60s backend timeout
• #38258 — Processes hang indefinitely with no timeout

This differs from those issues in that it specifically identifies the VS Code extension host ping/pong heartbeat mechanism as the root cause, rather than a WebSocket or OAuth issue.