OpenAI Responses decoder rejects object-shaped top_p from MiniMax

## Problem

Rig 0.41.0 fails to deserialize some successful MiniMax Responses API responses with:

```text
CompletionError: JsonError: invalid type: map, expected f64
```

The response contains a valid tool call, but deserialization fails before the tool call is exposed to the agent. The error is observed in non-streaming `CompletionModel::completion` responses used by structured-output tasks. The only response-wire field in the Responses decoder that expects `f64` at this layer is `top_p` (`Option` in `CompletionResponseWire` via flattened `AdditionalParameters`).

MiniMax supports the Responses API and structured tool calls; the failure appears to be a provider response-shape compatibility issue rather than unsupported tools. The same model can successfully complete the task through the streaming path.

## Environment

- Rig: 0.41.0
- Provider: MiniMax OpenAI-compatible Responses API
- Model: MiniMax-M3
- Task: single strict structured capture tool

## Expected

A response with a valid tool call should be parsed and delivered to the tool/hook even when optional provider metadata uses a compatible object shape.

## Possible fixes

- Make `top_p` response deserialization tolerant of provider object/null shapes or ignore it on response decoding.
- Normalize MiniMax-compatible response metadata before deserialization.
- Document that the streaming path is required for providers with this response dialect.

I can provide a sanitized raw response body if needed.

Look at the `CompletionResponseWire` struct and its `AdditionalParameters` flattening, focusing on the `top_p` field deserialization. The error indicates a map/object is received where an f64 is expected. Examine the MiniMax provider response shape and the streaming path that works. Start by adding debug logging or a test with a sample response to see the exact JSON structure. The fix likely involves making the deserialization more tolerant in the relevant decoder module.

由索引模型根據 Issue 內容生成。