ref(checkin): Measure check-in durations with Stopwatch (JAVA-576)

[runningcode]

📜 Description

All four check-in paths kept a start tick and subtracted it in a finally:

// before
final long startTime = System.nanoTime();
...
checkIn.setDuration(DateUtils.nanosToSeconds(System.nanoTime() - startTime));

// after
final @NotNull Stopwatch stopwatch = Stopwatch.started(JavaUptimeClock.getInstance());
...
checkIn.setDuration(DateUtils.nanosToSeconds(stopwatch.elapsedNanos()));

CheckInUtils plus SentryCheckInAdvice in sentry-spring, sentry-spring-jakarta and sentry-spring-7.

Stacked on #6030 → #6029 → #6028.

💡 Motivation and Context

The serialized duration is unchanged, to the bit. JavaUptimeClock.tickNanos() is System.nanoTime(), and check-ins have no Android path where uptime and elapsed real time could diverge. This is the same arithmetic behind a name.

That is the whole argument for landing it before the major. Everything else in this series that touches a customer-facing measurement is being held for v9; this one can go now precisely because naming the guarantee makes the conversion provably inert rather than merely believed to be.

Each site carries a // TODO [MAJOR] for the change that is not inert. On the elapsed-real-time clock, a cron job that spans device sleep would report the duration a user would measure rather than the CPU time it had — which is what a cron monitor's "duration" ought to mean, and what v9 should switch to.

The clock is resolved as JavaUptimeClock.getInstance() rather than read from options. It is a stateless singleton, so an uninitialised SDK reaches a working clock with no scopes lookup and nothing to configure. This also gives UptimeClock its first caller — it shipped in #6028 with none.

• resolves: JAVA-576

#skip-changelog

💚 How did you test it?

No new tests. The conversion is mechanical and the existing check-in tests already assert the emitted duration; a test that Stopwatch.started(JavaUptimeClock.getInstance()) measures elapsed time would be testing StopwatchTest a second time.

.api has no diff. sentry's check-in tests pass, and all four modules compile.

A pre-existing failure you should know about, since it is in the files this PR touches: SentryCheckInAdviceTest fails locally for me in all three Spring modules — 14 failures, expected:<1> but was:<0> on the captureCheckIn verifications. I confirmed it is not caused by this change by running the same tests on the base branch with the change stashed: 14 failures before, 14 after, identical set. It looks like a local environment problem rather than a repo one, but I could not rule that out from here, so CI on this PR is the real check.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

[linear-code]

JAVA-576

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.54.0 (1)	release

⚙️ sentry-android Build Distribution Settings