docs(livekit): set the session root span kind to conversation so calls reach the voice UI

[abhijaisrivastava15]

Both LiveKit pages tell you to type the one span kind that hides your call from the voice product.

What was wrong

The session root span is created with fi_span_kind="agent":

with tracer.start_as_current_span("LiveKit Agent Session", fi_span_kind="agent") as parent_span:

The voice call list is built by VoiceCallListQueryBuilder, and it selects on exactly two things (futureagi/tracer/services/clickhouse/query_builders/voice_call_list.py:123-124):

AND (parent_span_id IS NULL OR parent_span_id = '')
AND observation_type = 'conversation'

An agent root fails the second condition. So a LiveKit app instrumented by following our own page emits a correct, complete trace that the voice surface never returns. The page has said agent on both listings since it was written, which is every LiveKit reader we have had.

conversation is not something that needs adding. It already exists on both sides:

• FiSpanKindValues.CONVERSATION in fi_instrumentation/fi_types.py
• ObservationType.CONVERSATION = "conversation", added in tracer migration 0026

What changed

Page	Change
docs/integrations/traceai/livekit.mdx	root span kind agent to conversation, both listings
docs/tracing/auto/livekit.mdx	same, both listings

Four occurrences, plus one comment line so the next reader does not "correct" it back on a page whose span is named "Agent Session".

Why, reproduced not read

Two identical LiveKit-shaped traces were sent into one project on a local stack, differing only in the root's fi_span_kind.

Both landed:

┌─trace──────┬─observation_type─┬─name─────────────────────────────────┬─pos───┐
│ 1723777d-5 │ agent            │ LiveKit Agent Session [agent]        │ ROOT  │
│ 606a63d8-e │ conversation     │ LiveKit Agent Session [conversation] │ ROOT  │
└────────────┴──────────────────┴──────────────────────────────────────┴───────┘

The product's own endpoint, the one the voice grid calls, returns one of them:

GET /tracer/trace/list_voice_calls/?project_id=b5861c81-…

THE PRODUCT API RETURNS 1 call(s)
  - trace 606a63d8-e

606a63d8 is the conversation root. The agent root is absent.

Test cases

#	Scenario	Expected	Result
1	Root emitted with fi_span_kind="conversation"	stored as observation_type = 'conversation'	pass
2	Same trace through list_voice_calls	returned	pass
3	Root emitted with fi_span_kind="agent"	not returned by list_voice_calls	pass
4	fi_span_kind="CONVERSATION" (uppercase string)	raises, normalizer requires lowercase	pass
5	node scripts/audit-links.mjs	0 broken nav, 0 broken content	pass

Commands

node scripts/audit-links.mjs

Not in this PR

The voice grid is gated on project source, separately from the span kind. LLMTracingView.jsx:4454 renders the call-log grid only when projectDetail.source === "simulator", and a project created by an SDK push defaults to source = "prototype". There is a backend comment acknowledging the coupling in model_hub/utils/annotation_queue_helpers.py:1524.

So this PR is necessary and it is not sufficient. It makes the data correct and makes the call reachable through the voice API. Getting a self-hosted LiveKit project onto the voice grid also needs a product-side answer for how a pushed project gets the voice source. That is a code change, not a docs change, and it is being picked up separately.

The duplicate LiveKit page is also left alone here. docs/tracing/auto/livekit.mdx is byte-identical to the integrations copy apart from its frontmatter, and only the integrations copy is in the sidebar. Both are live, so both are fixed, but deduplicating them is its own call.