feat(telemetry): add complete adapter-function lifecycle observability #1466

Status

Deferred on 2026-08-27. This is now independent backlog work, not an active Epic #929 deliverable.

The reviewed draft PR #1558 implemented LocalFile activation/deactivation spans through the hook/plugin pattern, but that is only one slice of adapter observability. It was closed rather than merged because the broader capability needs a coherent lifecycle and metric contract across adapter realities.

Problem

Mellea needs useful, truthful observability for adapter-function work across LocalFile, Embedded, ServerMediated, and future bindings. The existing phase-duration metrics and any future spans must describe the same lifecycle without counting setup work as function invocation or fabricating an outcome before one exists.

Scope when resumed

• Define lifecycle boundaries and invocation semantics for each adapter reality.
• Add spans only where a real invocation outcome is available.
• Preserve existing metric-only events where no matching invocation exists.
• Cover LocalFile setup, activation, generation, parsing, and release as appropriate.
• Add equivalent observability for Embedded and future adapter realities when their real outcome paths are known.
• Decide whether content capture and metric exemplars are worth supporting, then make their trace context explicit.

Out of scope

• A LocalFile-only activation/deactivation slice.
• Treating setup work as an adapter-function invocation merely to create a span.
• Inventing spans for metric-only request edits.

Acceptance criteria

• Each supported adapter reality has documented lifecycle and invocation semantics.
• Spans and metrics agree on what counts as an invocation and a phase.
• No backend imports telemetry.tracing; plugins own span creation.
• Metric-only producers remain valid without fabricated trace correlation.
• Tests cover each supported adapter reality and its failure paths.