refactor(telemetry)!: move backend tracing onto plugin/hook pattern

[ajbozarth]

Pull Request

Issue

Fixes #1045, fixes #1046, fixes #1047. Phase 1 of #444. Also closes out item 2 of #909.

Description

Phase 1 of the tracing epic. Migrates backend span emission from inline calls scattered across five backends onto a BackendTracingPlugin that subscribes to the existing generation_* hooks (chat path) and new generation_batch_* hooks (raw path). Spans stay live on the OTel context across the API call so nested instrumentation (httpx, langchain) parents under the backend span.

Reviewer call-outs:

1. Breaking: env var rename. MELLEA_TRACE_* → MELLEA_TRACES_* (plural), aligned with OTEL_EXPORTER_OTLP_TRACES_ENDPOINT and MELLEA_METRICS_*. Adds MELLEA_TRACES_ENABLED umbrella flag and opt-in MELLEA_TRACES_OTLP. No deprecation shim — tracing was still pre-1.0 surface.
2. Breaking: gen_ai.system removed in favor of gen_ai.provider.name. Cleans up the dual emission introduced by feat(telemetry): close five OTel GenAI semantic convention emission gaps (#1035) #1036.
3. Additive: new hook surface. generation_batch_pre_call / generation_batch_post_call / generation_batch_error for plugin authors. Raw path now emits one span per generate_from_raw call (per OTel GenAI semconv), not one per MOT.
4. Architectural: spans now live on the OTel context during API calls. Chat and raw paths both keep the backend span active across the network call, so nested instrumentation parents under it instead of floating at the root.
5. Rebase artifact: ModelOutputThunk.cancel_generation (added upstream by feat(stdlib): add stream_with_chunking() with per-chunk validation (#901) #942 in 9e8a9636) had its body rewritten to fire GENERATION_ERROR instead of calling the removed _telemetry_span API. Reviewers may notice as "extra surface", but it's rebase-driven, not refactor-driven.

BREAKING CHANGE: Public telemetry API surface narrowed:

• MELLEA_TRACE_* env vars renamed to plural MELLEA_TRACES_* with no deprecation shim.
• The deprecated gen_ai.system span attribute is removed; consumers should read gen_ai.provider.name instead.
• The split helpers is_application_tracing_enabled() and is_backend_tracing_enabled() are replaced by a single is_tracing_enabled().
• The application-tracing helpers add_span_event, start_backend_span, end_backend_span, and trace_backend are removed from mellea.telemetry. Backend spans are now emitted by the BackendTracingPlugin automatically; application spans use trace_application (unchanged).
• The mellea.telemetry.backend_instrumentation module is deleted along with its exports (start_generate_span, instrument_generate_from_raw, record_token_usage, record_response_metadata, finalize_backend_span).

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code was added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

Attribution

• AI coding assistants used

---

Adding a new component, requirement, sampling strategy, or tool?

If your PR adds or modifies one of the types below, check the matching box. A checklist of type-specific review items will be posted as a comment.

• Component
• Requirement
• Sampling Strategy
• Tool

NOTE: Please ensure you have an issue that has been acknowledged by a core contributor and routed you to open a pull request against this repository. Otherwise, please open an issue before continuing with this pull request.

[ajbozarth]

Follow-up work spawned by this PR (not part of the tracing epic):

• refactor: subscribe metrics plugins to generation_batch_* hooks #1182 — pure additive; depends on the batch hook surface introduced here.
• refactor: move generate_from_raw hook firing into Backend base class #1183 — firing logic is currently duplicated across all 5 backends, mirroring the OLD chat-path pattern this PR cleaned up.

[ajbozarth]

I also opened #1180 which fixes a bug in metrics that also applies here. (ie that needs to merge first)

[jakelorocco]

looks good! I just have a few questions and a few places I think extra comments would be helpful.

[jakelorocco]

What happens if someone only registers the start_backend_span function and these finish span functions never run?

[ajbozarth]

As written in this PR, this can't happen, start_backend_span is only called from BackendTracingPlugin.on_pre_call / on_batch_pre_call, and each is paired with on_post_call + on_error (or the batch equivalents) on the same plugin. The astream / generate_from_raw paths guarantee that exactly one of post_call or error fires for every pre_call, so the span always closes.

The only way to leak a span is if a user writes their own code that calls start_backend_span directly without calling finish_backend_* to close it. In that case the entry sits in _in_flight_spans until process exit and the OTel context token never detaches.

[ajbozarth]

@jakelorocco I believe 00831a4 addresses all your actionable comments