Send a chat message's participant name to the provider

[deepfates]

What

A chat message's optional participant name (OpenAI chat format) now reaches the provider. Before, Imp dropped it in two places.

1. Client. Imp.Clients.ReqLLM read only role, content and tool calls when it built ReqLLM messages, so Imp.LM.generate(lm, [%{role: "user", content: "hi", name: "alice"}]) went out with no name. It now copies name (atom or string key) onto the ReqLLM.Message, whose OpenAI-compatible encoder writes it to the body. It only sets the name when the message has a non-empty one, so an unnamed message goes out exactly as before. Anthropic's encoder has no such field and ignores it. Generate, stream and batch all build their messages through the same to_req_messages/2, so this one change covers all three.
2. Adapter. Imp.Adapter.Chat built every history turn and the final request as %{role:, content:} only, so a host had no way to name a message.

API for hosts

History turns are signature-shaped field maps, and they already carry recorded keys besides the fields (tool_calls, next_thought, reasoning_details). Naming follows the same pattern:

history =
  Imp.History.new([
    %{question: "Who won?", answer: "Blue team.", user_name: "alice", assistant_name: "imp"},
    %{question: "By how much?", answer: "Two points.", user_name: "bob"}
  ])

Imp.Predict.call(predict, %{question: "Rematch?", history: history, user_name: "alice"})

• :user_name on a turn names that turn's user message. :assistant_name names its assistant message, including a native tool turn's assistant message. Tool results and notes are never named.
• :user_name in the request inputs names the final user message. Imp.Predict no longer warns about it as an extra input.
• These keys are message metadata and are never rendered as fields. A name is passed through as given; Imp does not check it, so if the provider rejects a malformed name, the error comes from the provider. If a signature declares a field called user_name or assistant_name, that field stays an ordinary field, so a key never means two things.
• The JSON and XML adapters build their messages through Chat's assembly, so they behave the same way.

The keys are not bare name because a signature field called name is common, and reusing it would turn an input value into a participant name.

Documented under "Naming messages" in Imp.Adapter.Chat, with a pointer from Imp.History. CHANGELOG has an Unreleased "Added" entry.

Not changed

• The TRL client sends only role and content (its protocol checks keys exactly), so it still ignores names.
• ReActV2 filters request inputs down to signature fields, so its request message is not named. Its held history turns are named.
• Renderers still return content only. The data keys above cover naming without a new renderer shape.

Tests

• The client sends the name for atom-key and string-key messages and leaves it out of the OpenAI wire body for an unnamed message.
• A streamed predictor carries the request's user_name through to stream_text.
• Adapter: named plain turns, string-keyed turns, unnamed turns, a native tool turn (its tool result is not named), a signature field called user_name that stays a field, and Imp.Predict with no extra-input warning.
• The new tests fail on main (5 failures) and pass here. mix check, quality.check and dialyzer.check all pass.