Optional OpenTelemetry instrumentation of resolution and finalization

[lesnik512]

Migrated from ROADMAP.md's ## Under consideration section, which is being deleted — an unscheduled item belongs in the tracker, not in a third hand-maintained file. See #438.

Why it is open

Emitting spans for resolution and finalization would make container behaviour
visible in an existing tracing backend rather than only in error text.

What it must clear first

• Zero dependencies. Core cannot depend on the OpenTelemetry SDK, so this
  would have to be optional and inert when the SDK is absent.
• The resolve hot path. resolver_compiler.py compiles one flat closure per
  provider and holds the per-node frame budget at 1 — an invariant with a test
  named after it. Instrumentation that adds a frame or a branch per node is not
  acceptable; a warm resolve is measured in nanoseconds.
• The declined neighbours. 0023-debug-resolution-tracing-declined
  already refused an in-house resolution tracer. A proposal has to say why
  exporting to OpenTelemetry escapes that reasoning rather than restating it.

Revisit trigger

A design that is inert without the SDK installed and costs nothing measurable on
the compiled resolver path.