Fix duplicate LSP server creation due to race condition

[SnaetWarre]

Problem

The LSP system was creating duplicate server instances when multiple calls to startForFile occurred simultaneously. This resulted in two LSP server processes being spawned for the same workspace/language combination.

Root Cause

The server tracking key was added to the activeLanguageServers Set after the async backend call completed, creating a race condition window where multiple concurrent calls could all see an empty Set and proceed to create duplicate servers.

Solution

• Moved server tracking before the backend invocation to eliminate the race condition
• Added error handling to remove the server from tracking if the backend call fails, maintaining consistency

Changes

• src/features/editor/lsp/lsp-client.ts: Reordered operations to add server key to Set before invoking backend, added try-catch for cleanup on failure
• src-tauri/src/lsp/manager.rs: Removed debug instrumentation (cleanup only)

Testing

Verified with instrumented logs that:

• Only ONE LSP server instance is created (instead of two)
• Race condition is eliminated even with 5ms timing difference between calls
• Deduplication works correctly for subsequent file opens
• Error handling maintains consistency

Impact

• Reduces resource usage by preventing duplicate LSP servers
• Improves LSP reliability and performance
• Eliminates confusing duplicate notification messages

[mehmetozguldev]

LGTM