Reproduce RUMS-5093: span timing bug with NTP clock drift

[mariusc83]

Summary

• Adds 3 failing reproduction tests for RUMS-5093 (Incorrect Timing and Ordering of Traces)
• CoreTracerSpanToSpanEventMapperTest: two tests prove that when device clock is ahead of server (negative serverTimeOffsetNs), map() shifts the serialized span start to before the actual request started (5s earlier), making the android.request span appear to have negligible duration vs. backend child spans
• KronosTimeProviderTest: one test proves that getServerOffsetMillis() returns a large negative value (-5000ms) when device clock is ahead of server, with no guard against this offset being blindly applied at serialization time
• DatadogHttpCodecTest: one passing test confirms that x-datadog-parent-id is correctly set to the span's own spanId — the visual broken ordering in the Datadog UI is caused by incorrect timestamps, NOT by wrong context propagation headers

Root Cause

CoreTracerSpanToSpanEventMapper.map() fetches serverTimeOffsetNs at serialization time (not at span creation time). When the device clock is ahead of NTP server time, this offset is negative, shifting the serialized span start timestamp to before the actual HTTP request was initiated.

Test plan

• Run :features:dd-sdk-android-trace:testDebugUnitTest — 2 REPRO tests fail, all others pass
• Run :dd-sdk-android-core:testDebugUnitTest — 1 REPRO test fails, all others pass
• Run :features:dd-sdk-android-trace-internal:testDebugUnitTest — 1 REPRO test passes (confirms propagation correctness), all others pass

🤖 Generated with Claude Code

[datadog-prod-us1-4]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 82.74% (+11.32%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 2615767 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}