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:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] 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