fix(realtime): keep the server's status when converting a conversation item

[ProjeetBhaumik]

This pull request fixes a realtime history regression where completed conversation items flip back to in_progress.

_ConversionHelper.conversation_item_to_realtime_message_item hardcoded "status": "in_progress", discarding the status carried by the server payload.

This is reachable in a default voice session. After the assistant produces audio, _current_item_id points at the assistant's audio item. When the user's next utterance finishes transcription, the handler for conversation.item.input_audio_transcription.completed sends conversation.item.retrieve for that item, and the server replies with conversation.item.retrieved carrying the item's real status (completed). The conversion rewrote it to in_progress, and the session history merge keeps the incoming status, so a completed assistant item regressed on every user turn with nothing to restore it. conversation.item.truncated triggers the same retrieve.

The fix passes item.status through, falling back to "in_progress" only when the server omits it. The GA conversation item models (RealtimeConversationItem{User,Assistant,System}Message) all declare status: Literal["in_progress", "completed", "incomplete"] | None, so the value is already on the parsed item. This matches what _handle_ws_event already does for response.output_item.added/.done, which reads the payload's status and only synthesizes one when it is absent.

Behavior note: items whose status the server does report now surface that status instead of a fabricated in_progress. That also applies to user and system items, which do not declare status on the SDK model and carry it as an extra field.

Fixes #4597

[seratch]

This PR implements the same explicit-status pass-through as #4598, but #4598 already covers the realistic audio/transcription-triggered retrieve path and is the selected destination for the remaining session-history regression test. To avoid maintaining parallel candidates for the same fix, I am going to close #4601 as a duplicate of #4598.