tracing(csharp): no driver-session root span — every top-level call creates a fresh TraceId

[eric-wang-1990]

Severity: Medium

Observation

Every top-level driver call creates a fresh root TraceId. Confirmed across all 33 E2E test classes:

• DatabricksConnectionTest: 193 TraceIds / 515 spans
• StatementTests: 501 TraceIds / 1,472 spans
• CloudFetchE2ETest: 830 TraceIds / 2,042 spans
• MemoryStressTests: 12,958 TraceIds / 37,950 spans (95% are single-span root ReadNextRecordBatchAsync)

ConcurrentDisposeTests confirms every DatabricksCompositeReader.Dispose and HiveServer2Connection.DisposeClient span has ParentSpanId=0 — so even within one connection, Dispose can't be linked back to the Execute that needed cleaning up. Cancel and Close TraceIds are completely disjoint from the Execute TraceId they relate to.

Confirmed at design-contract level: the 12 dedicated Telemetry/* self-tests all exhibit this structure and none assert on a session-root span — so this is the current contract, not an oversight in sampling.

Workaround that exists today

db.client.connection.session_id is on every statement span — backend filter-by-tag works for "show me everything from session X." ConcurrencyStress confirms 152 concurrent statements map cleanly to 8 distinct session_ids. So join-by-tag debug works, even though trace-tree visualization is broken.

Suggested fix

Either (a) introduce a long-lived ConnectionLifetime activity that all per-call activities chain under, OR (b) stamp adbc.connection.id + adbc.statement.id tags on every span explicitly and expect backends to group-by-tag.

Evidence

• Traces.MemoryStressTests.20260527_154049/ — 12,958 TraceIds / 37,950 spans
• Traces.ConcurrentDisposeTests.20260527_153028/ — every Dispose ParentSpanId=0
• Traces.CloseOperationE2ETest.20260527_144932/ — Dispose TraceIds disjoint from Execute