Fix: seed the user turn from OpenInference nested content-parts messages

[AshwinUgale]

What

The OTel/OpenInference adapter's _collect_messages read only the flat
llm.input_messages.N.message.content string. Many OpenInference instrumentors
(smolagents among them) instead emit the content-parts shape:

llm.input_messages.N.message.contents.M.message_content.text

Because that shape wasn't parsed, the user's own request was dropped from the
seeded input turns. With no record of what the agent observed, R3
(hallucinated-arg) falsely flagged an argument the user actually supplied
(e.g. order_id) as an underivable/hallucinated value.

This change collects the indexed text parts and joins them into content
(a flat message.content still wins when present).

Why it matters

This is a general OpenInference correctness fix, not a framework-specific
one — the content-parts shape is common across OpenInference instrumentation, so
the false positive affected any such trace.

How it was found & verified

Surfaced while linting a real agent trace via --format openinference. Verified
on a real gpt-4o-mini ToolCallingAgent run (genuine LLM spans, so the
user-prompt provenance was genuinely present in the trace, ruling out a
scripted-model artifact):

• Before: R3 [candidate] order_id=A100 not derivable — false positive.
• After: the trace lints clean, 0 findings.

Independently confirmed by collapsing the nested content into the flat form on a
copy of the spans and watching R3 vanish — isolating this parsing as the sole
cause.

Tests

tests/test_adapter_otel.py::test_input_messages_seed_from_nested_content_parts_shape
(built from the real trace). Full suite green.