feat(neuron): emit response.in_progress between created and output_item.added

Refs #7.

OpenAI's Responses API spec emits `response.in_progress` between
`response.created` and the first output-item event to mark
"request validated, model is generating". Some Responses-API
clients distinguish loading-spinner vs streaming-spinner UI based
on which event arrived last; emitting both keeps the wire shape
matched.

Carries the same shell as `response.created` (status=in_progress,
empty output, no usage yet) — both events are payload-light
bookkeeping, distinguished only by the event name.

The hosted-tool event families remaining in #7 (web_search_call,
code_interpreter_call, file_search_call, image_generation_call)
stay deferred until the underlying tools exist in neuron.

Updated `full_stream_emits_expected_event_sequence` to assert the
new event lands in position 1; downstream indexing shifted by one
across the existing test assertions. CI green, fmt + clippy clean.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

crates/cortex-core/src/responses.rs

@@ -212,6 +212,11 @@ pub struct ResponsesUsage {
 /// Responses API.
 pub mod events {
     pub const CREATED: &str = "response.created";
+    /// Fired between `response.created` and the first output-item
+    /// event. Marks "request validated, model is generating" —
+    /// some clients use it to differentiate the "warming up" state
+    /// from "streaming tokens" in their UI.
+    pub const IN_PROGRESS: &str = "response.in_progress";
     pub const OUTPUT_ITEM_ADDED: &str = "response.output_item.added";
     pub const CONTENT_PART_ADDED: &str = "response.content_part.added";
     pub const OUTPUT_TEXT_DELTA: &str = "response.output_text.delta";

crates/neuron/src/wire/openai_responses.rs

@@ -325,6 +325,19 @@ async fn emit_start_frames(tx: &mpsc::Sender<ResponseStreamFrame>, meta: &Respon
     let frames = [
         ResponseStreamFrame {
             event_name: events::CREATED,
+            data: json!({ "response": shell.clone() }),
+        },
+        // `response.in_progress` carries the same shell as
+        // `response.created` — both report the "in_progress"
+        // status and both are payload-light bookkeeping events.
+        // The distinction is meaningful to clients that
+        // differentiate "request validated" from "model is
+        // generating" in their UI (loading spinner vs streaming
+        // spinner). OpenAI's own Responses SSE emits them as a
+        // pair; matching the wire shape avoids subtle client
+        // breakage.
+        ResponseStreamFrame {
+            event_name: events::IN_PROGRESS,
             data: json!({ "response": shell }),
         },
         ResponseStreamFrame {
@@ -722,6 +735,7 @@ mod tests {
             names,
             vec![
                 events::CREATED,
+                events::IN_PROGRESS,
                 events::OUTPUT_ITEM_ADDED,
                 events::CONTENT_PART_ADDED,
                 events::OUTPUT_TEXT_DELTA,
@@ -733,15 +747,17 @@ mod tests {
             ]
         );
 
-        // The two deltas should carry the right text.
-        assert_eq!(frames[3].data["delta"], "hel");
-        assert_eq!(frames[4].data["delta"], "lo");
+        // The two deltas should carry the right text. Indices
+        // shifted by one after IN_PROGRESS inserted between
+        // CREATED and OUTPUT_ITEM_ADDED.
+        assert_eq!(frames[4].data["delta"], "hel");
+        assert_eq!(frames[5].data["delta"], "lo");
 
         // The done event has the full accumulated text.
-        assert_eq!(frames[5].data["text"], "hello");
+        assert_eq!(frames[6].data["text"], "hello");
 
         // Completed event carries the full message item.
-        let completed = &frames[8].data["response"];
+        let completed = &frames[9].data["response"];
         assert_eq!(completed["status"], "completed");
         let output = completed["output"].as_array().unwrap();
         assert_eq!(output.len(), 1);