fix: tolerate partial Responses output items

[yyy33]

Summary

Some OpenAI-compatible Responses providers return usable response.completed events while omitting envelope fields on final output items, such as id and status.

For example, a provider may return a final output item like:

{"type":"message","role":"assistant","content":[...]}

or a function call like:

{"type":"function_call","call_id":"call_abc","name":"shell","arguments":"{...}"}

The current streaming parser rejects those final response.completed events before Goose can consume the data that is actually needed. This causes the UI to display the streamed answer/tool call and then append a final stream decode error.

This change relaxes only the final output item envelope fields that Goose does not require:

• reasoning.id is optional
• message.id and message.status are optional
• function_call.id and function_call.status are optional

Function calls still require an identifier before producing a tool request. Goose now uses call_id first, then falls back to id, and returns an error if both are missing. This avoids synthesizing empty tool call identifiers.

This mirrors the practical handling used by OpenCode / AI SDK style Responses streaming, where function call handling is keyed by call_id and the final completed event is not treated as invalid solely because envelope fields are absent.

Tests

cargo test -p goose-providers

Result: 342 passed locally.

[DOsinga]

This is a clean, well-scoped fix — thanks! Making the streaming ResponseOutputItemInfo fields optional to match the non-streaming ResponseOutputItem is the right call, and the tests exercise the real parser end-to-end.

One thing worth following up on (here or in a separate PR): process_streaming_output_items and responses_api_to_message are now structurally the same 3-variant match, and this PR improved the function-call id handling on the streaming side (call_id.unwrap_or(id) + proper error) but left the non-streaming path at responses_api_to_message still using call_id.clone().or_else(|| id.clone()).unwrap_or_default() — i.e. the empty-string-id footgun you're fixing here still exists on that twin. It'd be nice to either apply the same fix there or unify the two into a shared helper so they can't drift. Not a blocker for this PR.

Approving.