No distributed tracing: nothing emits OpenTelemetry, so a caller's trace stops at this system

barakoCMS emits no traces. `grep -r 'OpenTelemetry\|ActivitySource\|traceparent'` over `barakoCMS/` returns nothing, and `Directory.Packages.props` has no OpenTelemetry package.

That is the largest gap between what this is and "a platform a distributed estate integrates with".

## What exists, and where it stops

`CorrelationIdMiddleware` reads or mints `X-Correlation-ID`, echoes it on the response, and pushes it into the Serilog context. #624 is already filed for the half of that problem inside this system: the id reaches the log and nothing stored carries it.

This issue is the other half. Even with #624 done, the id is ours. A caller that sent a `traceparent` gets no span back, its APM shows a gap where this system was, and a request crossing three services cannot be followed end to end.

## Why it matters more than it sounds

An architect deciding whether to put this in an estate asks two questions in the first hour: does it publish events, and does it show up in our traces. #688 explores the first. Nothing addresses the second.

It is also the cheapest thing on that list. ASP.NET Core, `HttpClient` and Npgsql all emit `Activity` already. Most of the work is registration and a decision about what to export, not instrumentation.

## What it would cover

- **W3C trace context**, so `traceparent` and `tracestate` are honoured inbound and propagated outbound. Outbound matters here: `Connectors`, `RequestAction` and `WebhookAction` all call third parties, and a trace that stops at our boundary is half a trace.
- **The spans already available for free**: ASP.NET Core, `HttpClient`, Npgsql. Marten emits its own activities too.
- **The spans that are ours**: the workflow runner, the job queue, the async daemon. Background work is exactly where a correlation id is most missed, because there is no request to grep for.
- **An exporter behind configuration**, off by default. A self-hosted deployment should not be sending telemetry anywhere it did not ask for.

## Questions worth settling

1. **Core or module?** Every other vendor-naming capability here is a module, and OTLP names a protocol rather than a vendor. Tracing that only works when an optional package is installed is a strange shape, so this probably argues for core with the exporter configured rather than referenced.
2. **Does it replace `X-Correlation-ID` or sit beside it?** Two ids for one request is worse than either alone. `Activity.TraceId` may be the id #624 should store.
3. **Metrics too, or traces first?** prometheus-net is already here and there is a metrics endpoint. Adding a second metrics pipeline needs a reason.
4. **What must never be on a span?** The same rule as logging: `LogSafe` exists because of CWE-117, and a span attribute carrying a token is the same defect in a new place.

## Done when

A `traceparent` sent to any endpoint produces a span that continues in an exporter, an outbound connector call carries the context onward, and the workflow runner's work appears under the request that caused it. Off unless configured.

Related: #624 (the correlation id stops at the log), #688 (events), #687 (durability).

Start with the existing CorrelationIdMiddleware and Directory.Packages.props, then inspect Connectors, RequestAction, WebhookAction, the workflow runner, job queue, and async daemon. Use the issue's grep command to confirm the current tracing gap and settle the core/module, correlation-id, metrics, and span-data questions. Done means inbound and outbound trace context, workflow spans, and a configurable exporter work without sending telemetry by default.

Written by the indexing model from the issue text.