Summary

Add an opt-in ActivityObserver that consumes already-emitted ContextLifecycleEvents and produces System.Diagnostics.Activity spans (named context.execute), so APM tools (Jaeger/Zipkin/OpenTelemetry) work without touching the core execution path.

Goal

Make the package observable "for free" in apps already using tracing, while keeping Core neutral to any telemetry technology.

Problem

ContextManager/ExecuteInContext already emits lifecycle events, but nothing turns them into standard spans. Consumers who want to correlate context execution with existing traces in Jaeger/Zipkin/OpenTelemetry have to hand-wire an observer and know the exact event shape.

Scope

• New ActivityObserver (in the Diagnostics layer) subscribed to ContextLifecycleEvent.
• Produces a span named context.execute on ExecuteInContext, with attributes context.type and context.id.
• Uses an injected ActivitySource (e.g. services.AddActivitySource("ModularityKit.Context.Shop")).
• Hosting example showing tracing with Jaeger/Zipkin.

Design Expectations

• Activity is never created inside ContextManager (Core) — per 10.3 the observer owns trace creation.
• The context stays immutable (no reference to Activity stored on IContext); correlation is carried via lifecycle-event tags per 1.9.
• Reduce span noise: document filtering; spans are opt-in via registration.
• Uses System.Diagnostics.DiagnosticSource / the modern TimeProvider-friendly API for testable timestamps.

Acceptance Criteria

• Adding AddActivitySource + registering the observer requires no change to application code that uses ExecuteInContext.
• Spans appear in Jaeger/Zipkin/OpenTelemetry with context.type and context.id.
• IContext remains immutable; no Activity property is added.
• Tracing is silent/absent unless the observer is registered.

Non-Goals

• No change to the Core runtime execution path.
• No APM-specific sink (OpenTelemetry/AppInsights teams handle export).
• No global relation registry kept by the library (tree is built externally, per 1.10/10.4).