editor: Limit document color responses (#2721)

Closes #2719

## Description

Limit a single LSP document-color response to 10,000 entries before the
editor
converts, sorts, retains, or renders it.

`update_document_colors` previously copied every `ColorInformation`
returned by
the provider into editor state. A very large response therefore caused
unbounded conversion and sorting work, persistent state growth, and
repeated
layout-time scans.

This change moves response conversion into a small bounded helper.
Responses at
or below the limit retain the existing conversion and sorting behavior.
Responses above the limit are rejected as a whole, leaving the
previously
accepted document colors unchanged instead of selecting an arbitrary
prefix.

The provider trait still returns an allocated `Vec<ColorInformation>`,
so this
consumer-side limit cannot prevent allocation performed by the provider
itself.
It bounds the component's additional conversion, sorting, retention, and
rendering costs without changing the provider abstraction.

The implementation and PR draft were generated with AI assistance. The
changes
were reviewed and tested with the repository's Rust test suite.

## How to Test

```console
cargo fmt --check
git diff --check
cargo test -p gpui-base
cargo check -p gpui-component-story --example editor
cargo run -p gpui-component-story --example editor
```

The boundary regression test verifies that exactly 10,000 entries are
accepted
and 10,001 entries are rejected. The complete `gpui-base` test suite
passes with
269 tests.

The complete Linux Editor story was also run with a temporary provider
response
containing 1,000,000 well-formed, non-empty, visible `0..1` ranges.
Together
with the four existing fixture colors, all 1,000,004 entries were
rejected at
the new limit check, and the UI remained in its event loop without a
panic until
the bounded test timeout. The temporary input and diagnostic logging
were
removed after the test.

## Performance Comparison

The complete Debug Editor binary was measured before and after the fix
on the
same Linux machine with the same 1,000,004-entry payload. Each process
ran for a
20-second sampling window. Peak RSS was sampled from
`/proc/<pid>/status` every
100 ms, and process CPU was read at the end of the window.

| Variant | Peak RSS | Process CPU | Alive after 20 s |
| --- | ---: | ---: | :---: |
| `upstream/main` (`f3ba893b`) | 1,339,664 KiB (1.28 GiB) | 100.0% | Yes
|
| This change | 264,208 KiB (258 MiB) | 5.9% | Yes |

With this workload, the limit reduced peak RSS by 1,075,456 KiB
(approximately
1.03 GiB, or 80.3%) and reduced process CPU by 94.1 percentage points.
The
measurement includes allocation of the provider's original response
vector in
both variants; the improvement comes from avoiding the component's
conversion,
sorting, retention, and layout processing for the oversized response.

These are single-run whole-process Debug measurements rather than a
microbenchmark, so they are intended to show the magnitude of the
bounded-path
improvement rather than provide a general performance guarantee.

An additional `cargo clippy -p gpui-base --tests -- -D warnings` run
reached the
changed crate but remains blocked by two pre-existing `nonminimal_bool`
warnings
in `crates/base/src/calendar.rs:131` on `upstream/main`. This PR does
not modify
that unrelated code.

## Checklist

- [x] I have read the [CONTRIBUTING](../CONTRIBUTING.md) document and
followed the guidelines.
- [X] Reviewed the changes in this PR and confirmed AI generated code
(if any) is accurate.
- [x] Passed `cargo run` for story tests related to the changes.
- [ ] Tested macOS, Windows and Linux platforms performance (if the
change is platform-specific).

Co-authored-by: Jason Lee <huacnlee@gmail.com>