Public conversation ID, emitted on OTel spans as gen_ai.conversation.id

[cpsievert]

Closes #307. Depends on posit-dev/chatlas#398 and tidyverse/ellmer#1106, which add the client-side conversation_id support this PR consumes.

Motivation

shinychat conversations have no identity that's visible outside the history store. This PR gives every conversation a stable ID and exposes it two ways:

1. Publicly, in app code: a new reactive accessor — chat$history$conversation_id() in R, chat.history.conversation_id() in Python — returning the active conversation's ID (NULL/None when history is disabled or the chat is still empty).
2. In telemetry: the ID is handed to the chat client, which records it as gen_ai.conversation.id on its own invoke_agent/chat OpenTelemetry spans — the standard attribute for this purpose in the OTel GenAI semantic conventions. shinychat itself emits no OTel spans.

Downstream impact (Commons)

chatlas and ellmer already emit GenAI spans; they just had no conversation identity to correlate by. With the client recording the ID on its own spans, Commons can group all model work (token usage, latency, errors) by conversation using the standard attribute — no shinychat-specific knowledge required, and first responses that fail or are cancelled are still attributed. shinychat deliberately stays out of OTel: no tracer, no span lifecycle, no otel dependencies — just one assignment before the model call.

The Commons-side consumption is a follow-up in the Commons repo, not this PR.

Semantics

• The ID is allocated at the first user submission — before any model work — so it's available to app code and telemetry from the very first response.
• It's stable across retries, restores, conversation switches, and set_client() / chat.client.set(), and the saved ConversationRecord adopts it.
• The ID is set on the client from a scalar captured at submission time, so in-flight work is never relabeled by later switches or client swaps.
• No ID is set when history is disabled. Greetings run before any ID exists. Conversation title generation clones the client after the ID is set, so title-generation spans also carry the ID — arguably correct, since they are model calls belonging to the conversation.
• Minor behavior change: on_active_id_change fires at first submission rather than first save, so with restore_mode = "url" the ?shinychat_conversation_id= param appears while the first response streams (reloading such a URL falls through restore gracefully).

Implementation

HistoryController gains active-identity state separate from the saved record (a submitted-but-unsaved draft has an ID and no record), with one invariant: when a record exists, its id equals the active ID. All restore/switch/init/delete/new-chat paths route through shared ops (activate_record() / clear_active()), and a single writer fires change notifications only on actual change.

• R: a reactiveVal tracks the live controller so the public reactive survives set_client()'s history re-registration; the replacement controller inherits the ID only for unsaved drafts (seeding a saved ID would risk overwriting the stored record). The ID is assigned to the client's conversation_id binding before the model call (capability-checked until the ellmer release lands).
• Python: the ID is assigned to the client's conversation_id property before the model call; requires chatlas >= 0.22.0 (temporarily resolved from Add settable conversation_id property to Chat chatlas#398 via tool.uv.sources until release).

Testing

• R: 25 tests in test-conversation-id.R; Python: 20 tests in test_conversation_id.py mirroring the R matrix (lifecycle, integration, client-binding handoff).
• Full pytest suite (225 passed), ruff, and pyright pass; R suite passes (2 pre-existing test-greeting.R failures also on main).
• Note: 6 Python files fail ruff format --check, all pre-existing on main and untouched here to avoid unrelated churn.