feat(tracing): opt-in handler-execution diagnostics on WolverineOptions.Tracking

[jeremydmiller]

Closes #2694. Supersedes #2690.

Summary

• Brings back the handler-execution tracing surface from Add activity events, tags and span for handler-execution timing #2690 (wolverine.handler.started/finished ActivityEvents, wolverine.envelope.transport_lag_ms / receive_dwell_ms tags, wolverine.deserialize span, wolverine.outbox.flushing/published events) but fully opt-in behind a new WolverineOptions.Tracking sub-config — every flag defaults to false, so apps that don't ask for the surface pay nothing for it.
• The original PR turned all of this on for every Wolverine app; this PR keeps the same surface, the same constants, and adds @lyall-sc as co-author on the commit.

New surface

opts.Tracking.EnableMessageCausationTracking      // moved from WolverineOptions
opts.Tracking.HandlerExecutionDiagnosticsEnabled  // wolverine.handler.started/finished + lag/dwell tags
opts.Tracking.DeserializationSpanEnabled          // wolverine.deserialize span + payload size
opts.Tracking.OutboxDiagnosticsEnabled            // wolverine.outbox.flushing/published

The legacy WolverineOptions.EnableMessageCausationTracking is kept as [Obsolete("Use Tracking.EnableMessageCausationTracking instead")] and delegates to the new home; in-tree readers (Executor, MessageHandler) are migrated to the new property to silence the warning.

Each new flag surfaces on ServiceCapabilities as an OptionsValue so CritterWatch can render which diagnostics this service has enabled. The Tracking sub-config itself is [ChildDescription].

How each flag wires up

Flag	Sites	Mechanism
HandlerExecutionDiagnosticsEnabled	HandlerChain.assembleFrames (events) + HandlerPipeline / Executor / TracingExecutor (tags)	Stamps MethodCall.ActivityEventBeforeCall / .ActivityEventAfterCall on every user handler; calls Activity.ApplyExecutionDiagnosticTags(envelope) helper
DeserializationSpanEnabled	HandlerPipeline.TryDeserializeEnvelope	Conditionally starts a wolverine.deserialize activity; tags payload size
OutboxDiagnosticsEnabled	HandlerChain.assembleFrames	Stamps MethodCall.ActivityEventBeforeCall / .ActivityEventAfterCall on every FlushOutgoingMessages postprocessor frame

No Wolverine-local ActivityEventFrame class — all ActivityEvent emission flows through JasperFx 1.30's new MethodCall.ActivityEventBeforeCall / .ActivityEventAfterCall properties (PR JasperFx/jasperfx#207). Bumps JasperFx 1.29.0 → 1.30.0 in Directory.Packages.props.

Envelope.ReceivedAt

New [JsonIgnore] DateTimeOffset? property set only in Envelope.MarkReceived(...). The receiver-side stamping that #2690 added to BufferedReceiver / DurableReceiver is not brought back — the single MarkReceived write covers every receiver path. Locked down by a regression test in EnvelopeTests.

Tests

• tracking_diagnostics_opt_in (new) — cross-cutting contract: all flags default false; handler.started/finished and the lag tag emit only when the handler-diagnostics flag is set; the deserialize activity is absent when the flag is off; the [Obsolete] causation shim round-trips both directions through the new home.
• EnvelopeTests.mark_received_stamps_received_at_with_the_supplied_clock (new) — asserts ReceivedAt is stamped with the timestamp the caller passes in (not DateTimeOffset.UtcNow taken inside).

Test plan

• dotnet test src/Testing/CoreTests --framework net9.0 — 1557/1557 passed, 0 failed
• Build clean across Wolverine, CoreTests, no Obsolete-warning churn

Attribution

@lyall-sc's #2690 supplied the original tracing-event/tag inventory, the docs, and the basic test scaffolding. Co-authored on the commit.

🤖 Generated with Claude Code