ref(core): Strengthen browserPerformanceTimeOrigin reliability check

[Lms24]

In browserPerformanceTimeOrigin, we test how reliable performance.timeOrigin (or its predecessor) is by comparing its timestamp against performance.now() - Date.now(). If the delta is larger than 1h, we take the fallback rather than performance.timeOrigin.

For some context, we do this because performance.timeOrigin is prone to several inaccuracies, most prominently because it will drift behind the actual current time if users suspend their devices (e.g. closing a laptop, shutting of a phone). This makes the monotonic clock of timeOrigin resume where it left off prior to the suspension. It does not resync with the actual wall clock time (for better or worse).

This PR now makes the reliability check more strict by decreasing the time window from 1h to just 5 minutes. This should catch time drift more often. Now that we improved the fallback via #18715, I think we can give this a shot.

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	11,712	-	8,543	+37%
GET With Sentry	2,016	17%	1,637	+23%
GET With Sentry (error only)	7,857	67%	5,691	+38%
POST Baseline	1,216	-	1,129	+8%
POST With Sentry	610	50%	545	+12%
POST With Sentry (error only)	1,082	89%	987	+10%
MYSQL Baseline	4,119	-	3,104	+33%
MYSQL With Sentry	561	14%	456	+23%
MYSQL With Sentry (error only)	3,357	82%	2,502	+34%

View base workflow run