text: Commit background parses that a newer streamed chunk overtook - #3344

Closes #2634

Description

This fixes the condition @huacnlee pointed out in #2634 (comment): the result receiver in TextViewState drops any background parse whose revision is not the latest one.

When a stream appends faster than the background parser finishes, the next push_str / set_text arrives while a parse is still running. By the time that parse's result reaches the receiver, state.revision has already moved on, so the result is dropped. The next parse has the same problem. During a steady stream every result is discarded, and the view only updates after the stream goes quiet. This also undoes MAX_COALESCED_UPDATES_PER_PARSE. That bound exists so sustained streams still render intermediate updates (#2371), but the intermediate results it produces always carry an older revision, so they were dropped too.

A result parsed after the last full replacement is a prefix of the current text, and committing it is safe. The background parser builds every append on top of the document it has accumulated, so later results still contain all of the text. This PR moves the receiver body into TextViewState::commit_parsed_update and changes only the discard rule:

• commit a result whose revision is at least full_update_revision and newer than committed_revision;
• discard a result from before the last replacement (its text is no longer a prefix of the current text) or one not newer than what is already committed (for example the baseline ack of a synchronous replacement).

Everything else in the commit path is unchanged.

Real-stream cadence

To check that a real LLM stream hits this, I streamed one answer from Spark-X2.5 (the open-weight XHToken/Spark-X2.5 reasoning model, served through iFlytek Astron's OpenAI-compatible API) and timed the deltas:

That is the same ~55–100 ms cadence reported in the issue, sustained for over two minutes while the model reasons. Any parse that takes longer than one gap gets overtaken.

How to Test

New tests in crates/base/src/text/state.rs:

• stream_commits_a_parse_that_a_newer_chunk_overtook: pushes a chunk, then pushes the next chunk before the first one's parse lands, and checks that the overtaken parse is committed. The final parse then brings in the rest.
• a_parse_from_before_a_replacement_is_discarded: a parse that lands after a (background) full replacement is still discarded.

cargo test -p gpui-base --lib
cargo clippy -p gpui-base --all-targets -- --deny warnings

I ran both on Linux in my fork's CI, along with a check that restores the old revision != state.revision rule and confirms stream_commits_a_parse_that_a_newer_chunk_overtook fails without the fix: https://github.com/FenjuFu/gpui-kit/actions/runs/36841533259 (1282 passed; the old rule fails the new test).

I could not run the Story app on my machine (Windows without the MSVC linker), so this is verified by the tests above, not by watching example-stream-markdown.

Checklist

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