bug(translation): normalized Chat replay loses reasoning field spelling

What happens

The OpenAI Chat decoder accepts assistant reasoning from either reasoning_content or reasoning. After normalization, the original field name is no longer available. If Switchyard rebuilds the Chat request, it emits the reasoning as reasoning.

For example, this assistant history:

{
  "role": "assistant",
  "content": "Visible answer",
  "reasoning_content": "Historical reasoning"
}

can become:

{
  "role": "assistant",
  "content": "Visible answer",
  "reasoning": "Historical reasoning"
}

Untouched same-format traffic may use the preserved request body and avoid this path. The problem appears when Switchyard must rebuild from its normalized request, including cross-format translation, disabled preservation, and request mutation.

Why it matters

Some OpenAI-compatible models require previous assistant reasoning to be returned under the same field name they produced. Together documents that the field is model-dependent and that callers should use the same field for input and output:

https://docs.together.ai/docs/inference/chat/reasoning

Changing the field name can cause a later turn or tool continuation to be rejected.

Expected behavior

A rebuilt request should use a reasoning field accepted by the selected target without duplicating the reasoning under both names.

The fix should account for both cases:

• faithful replay when the source and target use the same dialect;
• an explicit target choice when routing or translation changes the destination dialect.

Prior work

• #449 covered reasoning lost from assistant history.
• #460 tried emitting both field names. It was closed after review because duplicating the reasoning increases request size; the requested direction was a target-level reasoning format.
• ConductorOne reproduced the remaining field-name problem and proposed preserving source provenance in their fork: https://github.com/ConductorOne/Switchyard/pull/3

The fork PR is useful as a reproduction and prototype, but this issue does not prescribe its public protocol changes as the final implementation.

Start with the OpenAI Chat decoder's normalization path and the Switchyard request-rebuild path, then compare the ConductorOne fork prototype linked in the issue. Trace how source reasoning-field provenance and the target dialect are represented; done means same-format replay preserves the source spelling while translated requests select one accepted target field without duplication.