fix(provider): scope OpenAI Responses text reconciliation to one output item

[kevin9327]

The bug

reconcile_response_text repairs a stream whose output_text deltas are incomplete: when response.output_text.done or response.output_item.done reports a final text longer than what was streamed, the missing suffix is emitted as one more TextDelta.

Its baseline is wrong. text accumulated every delta of the whole response, but final_text only ever describes one output item:

let mut text = String::new();          // per response
...
"response.output_text.done" => {
    if let Some(final_text) = value.get("text").and_then(Value::as_str) {
        for event in reconcile_response_text(&mut text_open, &mut text, final_text) { yield event; }
    }

if final_text.starts_with(streamed.as_str()) && final_text.len() > streamed.len() {

A Responses stream routinely carries more than one text-bearing item — the model writes a sentence, calls a tool, then writes more, and each block is its own message item. From the second item onward, streamed holds the concatenation of all previous items, starts_with is false, and the repair silently stops happening.

Failure mode

An assistant turn that ends in blank text.

When an upstream relay reports text only through terminal events and never sends response.output_text.delta — a common shape for OpenAI-compatible gateways — the reconciler is the only thing emitting text. Item 0 is emitted correctly, and every later item is dropped entirely, because the accumulator it is checked against is no longer empty:

event	streamed before	final_text	emitted
output_item.done (message, output_index 0)	""	"checking the file"	TextStart, TextDelta("checking the file")
output_item.done (function_call, 1)	—	—	tool call, fine
output_item.done (message, output_index 2)	"checking the file"	"the file looks fine"	nothing

The same wrong baseline also disables the partial-delta repair for any later item, so a truncated delta stream loses its tail instead of being completed.

The fix

Track the output_index the accumulator belongs to, and clear it when the provider moves to a different item, so each item reconciles against its own deltas. This mirrors how tool state is already keyed by output_index in this file.

Two properties are preserved deliberately:

• Events that omit output_index keep the current scope, so lenient relays behave exactly as before — nothing new is made required_u64.
• Repeated reports for one item (response.output_text.done followed by response.output_item.done) resolve to the same index, so they still share a baseline and cannot replay the same text twice.

Verification

cargo +1.95 test --package cursor-server --lib provider::openai_responses

Before (fix neutered in place, tests kept):

---- a_later_output_item_reconciles_against_its_own_text stdout ----
assertion `left == right` failed
  left: []
 right: [TextStart, TextDelta("the file looks fine")]

---- a_later_output_item_still_repairs_a_truncated_delta_stream stdout ----
assertion `left == right` failed
  left: []
 right: [TextDelta("looks fine")]

test result: FAILED. 2 passed; 2 failed

After:

test provider::openai_responses::tests::repeated_reports_for_one_output_item_do_not_replay_its_text ... ok
test provider::openai_responses::tests::a_later_output_item_reconciles_against_its_own_text ... ok
test provider::openai_responses::tests::a_later_output_item_still_repairs_a_truncated_delta_stream ... ok
test provider::openai_responses::tests::reasoning_replay_projects_response_items_to_valid_input_items ... ok

test result: ok. 4 passed; 0 failed

Gates (make check, Rust half):

• cargo fmt --all -- --check — clean
• cargo clippy --workspace --all-targets -- -D warnings — clean on CI's stable; see note below
• cargo test --workspace --all-targets — passes, apart from a pre-existing local flake in cursor_trace_queue::trace_producers_do_not_wait_for_sqlite_and_artifacts_stay_ordered (a 10 ms-poll timing assertion, 1 failure in 5 runs on this Windows box, unrelated to this change; green in CI on main).

Toolchain note: this machine's stable is broken, so the gates were run with +1.95. Clippy 1.95 reports one collapsible_match error in server/src/cursor/compile/model.rs:109 on unmodified main — that is a 1.95-only false positive (its own suggestion, "fast" if parse_bool(parameter)? =>, does not compile, since ? is not allowed in a match guard) and CI's 1.98.1 does not emit it, so main is green. Clippy here was therefore run with -A clippy::collapsible_match; nothing in this diff is affected either way.

[leookun]

Are you a robot 😂?

[kevin9327]

Human, I promise 😄 A Korean developer in my 30s who basically codes around the clock, so the PRs land at odd hours. Happy to answer anything on any of them.