What does this PR do?

Makes the lazy traceID.hexEncoded cache (introduced in #4481) safe under concurrent reads. (*traceID).HexEncoded no longer writes the cache from a read path; the cache is now populated eagerly at construction finalization for the context-extraction paths, and HexEncoded falls back to a non-caching hex.EncodeToString if the cache is empty (so concurrent readers can never race on the string write).

Concrete changes:

• (*traceID).HexEncoded is now a pure read with a non-caching fallback.
• Renamed computeAndCacheHex → cacheHex, with a doc comment stating it must be called at construction finalization, before the enclosing SpanContext is shared.
• Call cacheHex() at the trace-ID extraction finalization sites, where the resulting SpanContext is about to be returned and may then be injected concurrently:
  • FromGenericCtx (all three return paths)
  • extractTextMap (Datadog propagator)
  • extractTraceID128 (covers B3 single/multi and W3C parseTraceparent)
  • spanContextFromTraceComment (sqlcomment Extract)
• newSpanContext (the local StartSpan path) intentionally does not call cacheHex(): caching there would add an allocation to every span creation, including spans that are never injected. Local spans rely on the non-caching HexEncoded fallback instead, which is race-free because the fallback performs no write.
• Test helpers traceIDFrom64Bits / traceIDFrom128Bits finalize via cacheHex.
• New regression test TestConcurrentInjectTraceIDHex reproduces the race under -race (fan-out Inject on a shared SpanContext with an empty hex cache); fails on main, passes with this fix.

Motivation

PR #4481 cached the hex form of traceID to avoid millions of hex.EncodeToString allocations per second on the propagation hot path. The cache used a check-then-act lazy write with no synchronization:

func (t *traceID) HexEncoded() string {
    if t.hexEncoded == "" {
        t.computeAndCacheHex()
    }
    return t.hexEncoded
}

A KafkaWriter fan-out crashed with panic: runtime error: invalid memory address or nil pointer dereference in isValidPropagatableTag. Two goroutines call Inject on the same SpanContext; both see an empty cache, both write to t.hexEncoded, and a torn read of the Go string header ({ptr,len} is 16 bytes, not atomic) yields {nil, 16}. The downstream for _, ch := range v then dereferences the nil pointer.

Stack from the crash: tracer/util.go:41 ← textmap.go:481 ← propagating_tags.go:95 ← textmap.go:463 (injectTextMap → setPropagatingTag(ctx, keyTraceID128, ctx.traceID.UpperHex())).

-race confirmed the same race directly: Read at spancontext.go:52 (check) vs. Previous write at spancontext.go:106 (computeAndCacheHex).

All traceID mutation sites are construction-time (before the SpanContext is shared across goroutines), so the read path can be made a pure, race-free read: extracted contexts populate the cache eagerly at finalization (keeping the inject hot path zero-alloc for propagated spans), while locally created spans fall back to a non-caching computation that performs no write. Affected released versions: v2.8.0-dev, v2.8.0-rc.1, v2.8.0-rc.2, and v2.8.0.

Note on the local-span path: because newSpanContext does not populate the cache, HexEncoded/UpperHex on a locally started span allocates on each call (e.g. per Inject, and once at span finish via setTraceTagsLocked). This is a deliberate trade to keep span creation allocation-free.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running make lint locally.
• New code doesn't break existing tests. You can check this by running make test locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• All generated files are up to date. You can check this by running make generate locally.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running make fix-modules locally.