fwcd.kotlin 0.2.36: excessive CPU/memory usage and orphaned Kotlin language server processes in Remote-SSH

## Summary

The Kotlin extension can leave Kotlin language server processes running after a Remote-SSH VS Code session ends. In a large multi-module Gradle/Kotlin workspace, two language server instances together consumed about 35 GiB RSS and 14 logical CPU cores.

One of the instances became orphaned (`PPID=1`) and continued consuming resources indefinitely.

## Environment

- Extension: `fwcd.kotlin` 0.2.36
- Kotlin language server: 1.3.13
- VS Code Server over Remote-SSH
- Linux host
- Large multi-module Gradle/Kotlin workspace
- Host resources: 20 logical CPU cores, about 90 GiB RAM

## Actual behavior

Two processes of the following form were running simultaneously:

```text
java -DkotlinLanguageServer.version=1.3.13 ... org.javacs.kt.MainKt
```

Observed resource usage:

| Process | Parent | CPU usage | RSS memory |
| --- | ---: | ---: | ---: |
| First language server | `PPID=1` (orphaned) | ~5.9-7.8 CPU cores | 16.6 GiB |
| Second language server | VS Code extension host | ~5.4-8.0 CPU cores | 18.2 GiB |

Combined impact:

- About 34.8 GiB resident memory
- About 14 logical CPU cores continuously used
- System CPU idle dropped to roughly 5-9%

The extension log repeatedly contained symbol-index updates, with the symbol count approaching 80,000:

```text
[Info] async4 Updating symbol index...
[Info] async4 Updated symbol index in 0 ms! (79856 symbol(s))
```

The old language server was not cleaned up after its VS Code session ended. Sending `SIGTERM` did not stop either process within several seconds; `SIGKILL` was required.

After killing the active server process, the still-running extension host immediately launched another language server instance. Reloading or restarting the Remote-SSH extension host was required to stop the respawn.

## Expected behavior

- At most one language server should run per active VS Code workspace/session.
- Language server processes should terminate when the corresponding Remote-SSH extension host/session closes.
- Memory and CPU usage should remain bounded, including while indexing large workspaces.
- The extension should not continuously consume multiple CPU cores and tens of GiB of RAM after indexing has completed.

## Reproduction notes

I do not yet have a minimal reproduction. The issue occurred after opening a large multi-module Gradle/Kotlin workspace through Remote-SSH and leaving the VS Code Server session active for several hours.

I can provide additional process details or logs if needed.

No source file or test is named. Start by reproducing the large multi-module Gradle/Kotlin workspace over Remote-SSH, then inspect extension-host logs and the org.javacs.kt.MainKt process tree during session closure and respawn. Done means one server per active session, clean termination when the host closes, and bounded CPU and memory usage after indexing.

Written by the indexing model from the issue text.