fix: use OTel trace ID for PropagationContext.traceId — align with LedgerTraceListener

[mdproctor]

Problem

PropagationContext.traceId is set at case creation via UUID.randomUUID().toString() — a random UUID string.

LedgerTraceListener (@PrePersist on LedgerEntry) populates LedgerEntry.traceId from the active OTel span via LedgerTraceIdProvider.currentTraceId().

These are two different values for the same case. A CaseLedgerEntry written during an HTTP request will have:

• traceId from LedgerTraceListener = W3C OTel trace ID (e.g. "4bf92f3577b34da6a3ce929d0e0e4736")
• PropagationContext.traceId = UUID (e.g. "550e8400-e29b-41d4-a716-446655440000")

These cannot be correlated in Jaeger/Grafana/any distributed tracing tool. The case cannot be found by trace ID; the trace cannot be found by case ID.

Fix

In CaseHubReactor.createCase() (or wherever PropagationContext is constructed), populate traceId from LedgerTraceIdProvider.currentTraceId() instead of UUID.randomUUID():

@Inject LedgerTraceIdProvider traceIdProvider;

var ctx = PropagationContext.builder()
    .traceId(traceIdProvider.currentTraceId())  // ← was UUID.randomUUID().toString()
    .deadline(...)
    .build();

quarkus-ledger is already a dependency via casehub-ledger. LedgerTraceIdProvider is a CDI bean.

If no active OTel span exists (e.g. background trigger), fall back to UUID.randomUUID().toString() — same as current behaviour.

Why this matters

A customer filing a complaint about a case outcome needs a single trace ID to pull the complete picture across all services. Without alignment, support engineers must correlate manually across database tables and log files.

Part of

casehubio/parent#4 (platform coherence audit — finding #28)