OpenTelemetry performance timestamps produce past-dated spans and inflated durations #25743

With Sentry JavaScript SDK 11.9.0's OpenTelemetry tracer provider installed, numeric TimeInput values from performance.now() are forwarded to the core span API without conversion:

const start = performance.now();
const span = trace.getTracer('example').startSpan('client component loading', {
  startTime: start,
});
span.end(start + 25);

The resulting serialized span has a start near 1970 and a duration of 25 seconds. OpenTelemetry numeric timestamps are milliseconds; the expected duration is 0.025 seconds with a Unix-epoch start timestamp.

This occurs with the real NextNodeServer.clientComponentLoading span in Next.js 16.4.3, where it can inflate the enclosing trace's displayed duration to decades. The malformed timestamps are already present in the SDK envelope before ingestion.

The provider needs to distinguish OpenTelemetry's relative/epoch milliseconds from the direct Sentry API's numeric seconds, for both explicit starts and explicit ends.