Currently, in the raw_model_stream_event type, when the data.type field is "model", we expose an event field whose type is declared as any (courtesy of StreamEventGenericItem). This means consumers lose all type-safety and autocompletion on the shape of the event payload.

Steps to Reproduce:

1. In the OpenAI client, import or interact with the streaming API.
2. Inspect the TypeScript definition of raw_model_stream_event.
3. Note that data.event is typed as any under the hood.

export declare const StreamEventGenericItem: z.ZodObject<{
    /**
     * Additional optional provider specific data. Used for custom functionality or model provider
     * specific fields.
     */
    providerData: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodAny>>;
} & {
    type: z.ZodLiteral<"model">;
    event: z.ZodAny;
}, "strip", z.ZodTypeAny, {
    type: "model";
    providerData?: Record<string, any> | undefined;
    event?: any;
}, {
    type: "model";
    providerData?: Record<string, any> | undefined;
    event?: any;
}>;

Expected Behavior:

• The event property should be strongly typed to match what the API actually returns for model-stream events.
• We should leverage the existing ResponseStreamEvent type defined in openai/resources/responses/responses.mjs rather than falling back to any.

Suggested Solution:

• Update the definition of StreamEventGenericItem<T> (or wherever StreamEventGenericItem is used) so that when data.type === 'model', the event field is typed as ResponseStreamEvent.
• Ensure that ResponseStreamEvent is properly imported from openai/resources/responses/responses.mjs.
• Add any needed unit tests or type assertions to verify that the change provides correct type-checking and does not break existing uses.

Additional Context:
The change will improve DX by restoring full type-safety and IntelliSense when handling streaming responses from model endpoints. This aligns with the rest of the client library’s emphasis on precise typings.