LSP: first request in a session fails with "server is starting" instead of being queued until the server is ready

Environment

• Claude Code 2.1.170, Linux (Debian 12), headless (claude -p)
• Plugin: csharp-lsp@claude-plugins-official → csharp-ls 0.24.0 (behind a logging stdio proxy, which is how the timeline below was captured)

What happens

In a fresh session, the first LSP tool call can fail immediately with:

Error performing findReferences: Failed to sync file open /home/valtter/nagios-cli/src/NagiosCli/Rendering/Column.cs: Cannot send notification to LSP server 'plugin:csharp-lsp:csharp-ls': server is starting

Retrying the identical call a moment later succeeds. The request is rejected client-side while the server is in its starting state, rather than being queued and dispatched once initialization completes.

Evidence the server was healthy

A wire trace from the stdio proxy sitting between Claude Code and csharp-ls for the same session:

14:35:22 client->server request id=0 initialize
14:35:23 server->client response id=0            <-- init handshake done in ~1s
14:35:23 client->server textDocument/didOpen
14:35:23 client->server request id=1 textDocument/documentSymbol
14:35:28 server->client response id=1            <-- full result
14:35:34 client->server request id=2 textDocument/references
14:35:35 server->client response id=2            <-- full result, <1s

The failed findReferences attempt never reached the wire — only the retry (id=2) did. So this is purely the client's startup gate, not a slow or broken server.

Expected

Requests issued while the LSP server is starting should be queued (or transparently retried) once the server reaches ready state, instead of surfacing a transient error the model then has to notice and retry. The window is only a few seconds, but it's the first call of a session that hits it, so in practice it taxes every cold session.

Possibly related

Same client-side state gate, different symptom: in a longer-lived session the gate can wedge permanently rejecting with "server is running" — documented with traces in https://github.com/GabrielFarfan/csharp-ls-proxy/issues/4.