fix(openai): treat explicit null tool_choice as absent/default in Responses translation

[Artemon-line]

Fixes #1266

Summary

The Responses-to-Chat translator previously rejected requests containing an explicit "tool_choice": null with error 400 Bad Request: unsupported Responses tool_choice type for Chat Completions translation: null.

In OpenAI's Responses API, sending "tool_choice": null behaves identically to omitting the tool_choice field (defaulting to "auto" when tools are present).

This change updates build_chat_tool_choice to treat Value::Null as Ok(None), omitting tool_choice from the translated Chat Completions request and allowing requests with "tool_choice": null to succeed.

Testing Instructions (Real OpenAI)

1. Set your OpenAI API key in your environment:

   export OPENAI_API_KEY="sk-..."

2. Run the proxy with an OpenAI-backed configuration:

   cargo run -p praxis-ai-proxy --features full,store-sqlite -- --config <config.yaml>

3. Send a request with explicit tool_choice: null:

   curl -i http://localhost:8080/v1/responses \
     -H "Content-Type: application/json" \
     -d '{
       "model": "gpt-4o-mini",
       "input": "Hello",
       "tools": [
         {
           "type": "function",
           "name": "get_weather",
           "parameters": {"type": "object", "properties": {}}
         }
       ],
       "tool_choice": null
     }'

Expected Results:

• Returns an HTTP/1.1 200 OK response from OpenAI.
• The JSON response body echoes "tool_choice": null and returns a completed assistant response item.
• Requests with explicit tool_choice: null no longer return 400 Bad Request: unsupported Responses tool_choice type for Chat Completions translation: null.

[Artemon-line]

@leseb it's green, pls take a look 👍

[leseb]

[MAJOR] Null leaks into synthesized Responses output
File: chat_completions.rs:1258
Explicit null is omitted upstream, but remains Null in ResponsesState. Buffered and streaming response builders then emit "tool_choice": null instead of "auto".
This violates the OpenResponses response schema, which requires a string/object tool choice.
Normalize the response-side value and test both finite and SSE output.
[MAJOR] Required inference-fixture coverage is missing
File: test_openai_responses_vllm.py:6738
Repository instructions require transformation changes to update the inference scenario, recording, coverage manifest, and generated README.
Existing tests only verify success/status, so they miss the invalid echoed value.

[Artemon-line]

[MAJOR] Null leaks into synthesized Responses output File: chat_completions.rs:1258 Explicit null is omitted upstream, but remains Null in ResponsesState. Buffered and streaming response builders then emit "tool_choice": null instead of "auto". This violates the OpenResponses response schema, which requires a string/object tool choice. Normalize the response-side value and test both finite and SSE output. [MAJOR] Required inference-fixture coverage is missing File: test_openai_responses_vllm.py:6738 Repository instructions require transformation changes to update the inference scenario, recording, coverage manifest, and generated README. Existing tests only verify success/status, so they miss the invalid echoed value.

Addressed in 2fcb5ac

[leseb]

@Artemon-line ResponsesState normalizes null to "auto", but openai_client_tool_compat snapshots the raw null and later removes tool_choice from responses containing rich tools such as custom or shell. That still violates the required response schema in the composed finite/streaming pipeline. I left an inline Conductor comment at state.rs:926.

[Artemon-line]

Good catch @leseb! Addressed in 9dc9e8b -- restore_snapshot_tools now normalizes null snapshot tool_choice to "auto" instead of removing tool_choice from the response.