Python: [Bug]: AG-UI provider IDs replace request thread and run IDs

[moonbox3]

Description

When an AG-UI request supplies a stable threadId and a unique runId, the Python agent adapter can replace those lifecycle identifiers with conversation or response identifiers returned by the underlying chat provider.

This is visible with FoundryChatClient: separate turns in one AG-UI thread can be reported under different gen_ai.conversation.id values, so Foundry traces do not group the interaction as one conversation. The replacement can also cause thread snapshots to be keyed by a provider identifier rather than the AG-UI thread identifier.

Expected behavior:

• threadId identifies the stable AG-UI conversation across runs.
• runId identifies one execution within that thread.
• Provider conversation and response identifiers remain available for provider-side continuation, but do not replace the AG-UI lifecycle identifiers.
• If the AG-UI request omits an identifier, the provider identifier can be used as a fallback.

The native workflow endpoint already preserves request thread and run identifiers for lifecycle state, but its root and nested agent spans also need the AG-UI thread correlation context.

Code Sample

1. Host an `Agent` backed by `FoundryChatClient` through `add_agent_framework_fastapi_endpoint`.
2. Send two requests with the same `threadId` and different `runId` values.
3. Have the provider return a different response or conversation identifier for each turn.
4. Inspect the exported spans and thread snapshots.

Error Messages / Stack Traces

No exception is raised. The defect is visible as incorrectly separated traces and lifecycle state keys.

Package Versions

agent-framework-ag-ui: 1.0.0, agent-framework-core: 1.12.1

Python Version

Python 3.13

Additional Context

This is separate from #7338, which concerns uniqueness of workflow activity message IDs.