Revisit: replace 2-second sleep before typescript.restartTsServer with a readiness signal

Context

In ClustersExtension.ts, ensureTsRestart waits 2000 ms before issuing typescript.restartTsServer:

await new Promise((resolve) => setTimeout(resolve, 2000));
await vscode.commands.executeCommand('typescript.restartTsServer');

The comment explains: "Without this delay, the restart command can arrive while the server is still starting, causing a crash."

This is a magic number. On a slow or cold-start machine the TS server may still be initializing after 2 s, in which case the restart can fail. On fast machines the wait is unnecessary user-perceived latency.

Telemetry coverage for this code path was added in 0.8.1 (event playground.tsPluginBootstrap, property stage = 'tsWait' | 'tsRestart'), so we will get a real signal about failure rates once 0.8.1 is in users' hands.

Suggested solutions

1. Replace the fixed 2 s delay with a polling loop that checks for a more reliable readiness signal. Candidates to investigate:
   • vscode.extensions.getExtension('vscode.typescript-language-features')?.exports once it becomes non null.
   • vscode.languages.getLanguages() returning typescript consistently.
   • Tracking vscode.workspace.onDidOpenTextDocument for the first typescript or typescriptreact document since extension activation.
2. Use exponential backoff with a hard cap (for example 200 ms, 500 ms, 1 s, 2 s, 4 s) and emit telemetry on each retry so we can correlate restart latency with reliability.
3. Investigate whether the official TS extension exposes an API surface to wait for serverStarted or to register plugins post hoc, so we can avoid the restart entirely.

Definition of done

• The tsWait stage no longer relies on a fixed delay.
• playground.tsPluginBootstrap telemetry shows reduced failure rate at the tsRestart stage in the field.

Start in src/documentdb/ClustersExtension.ts at ensureTsRestart and review the existing playground.tsPluginBootstrap telemetry stages. Investigate the listed VS Code readiness signals and whether the official TypeScript extension exposes a server-started API before choosing an approach. Done means tsWait no longer uses a fixed delay and field telemetry shows fewer tsRestart failures.