#22375 reports a valid bug which is that timestampInSeconds() may return an inaccurate time stamp, since we don't detect clock drift between the performance.timeOrigin + performance.now() timestamp and Date.now().

This PR intentionally only partially fixes this problem by adding a clock drift check only to the initial timestampInSeconds call. This should account for cases where the monotonic performance.now() clock is already off at SDK init time but won't catch clock drift later on.

From here we have two options:

1. Also add the drift validity check to subsequent calls. This means we'll bypass caching (what we do now) until we detect clock drift, adding performance overhead by running the validity check on every timestampInSeconds call until then.
2. Drop using the performance time APIs entirely and only return Date.now(). This should give us more accurate timing overall but:
   • we loose nanoseconds precision
   • we'd arguably now report accurate and inaccurate times in one trace because some spans are created from PerformanceEntry entries, which include relative timestamps that might have also suffered from clock drift.

I also still need to look at the sent_at header which should prompt Relay to perform clock-drift normalization but I'm not yet sure to which extent.

Keeping this draft as a possible mitigation open for now