lsp: Bound the incoming language server message queue

[Anthony-Eid]

The background task reading a language server's stdout pushed every parsed message into an unbounded channel consumed on the foreground thread. If the main thread stalled while a server kept emitting notifications, messages accumulated at wire speed with no limit — matching the report in #58190 of 391 GB of memory growth during a multi-hour hang with a chatty server.

This bounds the queue at 128 messages. When full, the reader stops reading the server's stdout, so the OS pipe applies back pressure to the server instead of Zed buffering its output in memory. No messages are dropped, and healthy operation is unaffected. In flight client requests behind a full queue fail via their existing background executor timeouts.

Adds a regression test that wedges the consumer, asserts the queue stays bounded, then drains it and asserts no messages were lost.

Helps with #58190 and may also help with #31461.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards (UX/UI and icon guidelines)
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Release Notes:

• lsp: Improve Zed's memory usage when LSP's emitted messages faster than the foreground thread can handle them