Clean up the remaining AndroidCurrentDateProvider usages

Follow-up to getsentry/sentry-java#6102, which deprecates AndroidCurrentDateProvider but migrates nothing. Five internal call sites still use it, each carrying a @SuppressWarnings("deprecation") that points here.

Why they should move

AndroidCurrentDateProvider.getCurrentTimeMillis() is SystemClock.uptimeMillis(), which stops advancing while the device is in deep sleep. Any interval measured with it under-reports real elapsed time, so a window looks un-expired long after it actually expired. MonotonicTicker is CLOCK_BOOTTIME via SystemClock.elapsedRealtimeNanos() and keeps counting through deep sleep.

Call sites

Debouncer — internal/util/Debouncer.java reads the provider for its window check. Four constructions pass the uptime provider:

• ViewHierarchyEventProcessor (2 s window)
• ScreenshotEventProcessor (2 s window)
• SystemEventsBreadcrumbsIntegration (60 s window)
• AppComponentsBreadcrumbsIntegration (60 s window)

The two 60 s breadcrumb debouncers are the ones that can swallow a real breadcrumb: a trim-memory or connectivity event right after a long Doze can land inside a window that expired hours ago in wall time. The 2 s screenshot and view-hierarchy windows are much harder to hit. Note this is a behavior change, not a rename — the debounce interval starts counting deep sleep.

AndroidEnvelopeCache — currentDateProvider.getCurrentTimeMillis() - sdkInitTimeSpan.getStartUptimeMs(), the startup-crash detection threshold. Same deep-sleep skew: a crash long after init, with sleep in between, can fall under startupCrashDurationThresholdMillis and be written as a startup crash.

AndroidEnvelopeCache cannot move in isolation

TimeSpan is documented and implemented on SystemClock.uptimeMillis() (performance/TimeSpan.java:14, :45, :51). Moving only the left operand to a MonotonicTicker tick would subtract two different clock bases — worse than what is there today. Either move TimeSpan's base along with it, or split this call site into its own issue.

Out of scope

• sentry-android-replay's ICurrentDateProvider consumers — getsentry/sentry-java#5578 / PR #6090.
• Deleting AndroidCurrentDateProvider. The class is @ApiStatus.Internal and absent from sentry-android-core.api, so removal is not a binary-compat break, but per the project plan removal lands on v9.

Done when

• No production code references AndroidCurrentDateProvider, or the only remaining reference is AndroidEnvelopeCache with the TimeSpan coupling tracked separately.
• Every @SuppressWarnings("deprecation") added by getsentry/sentry-java#6102, and its comment, is gone.
• Tests cover a deep-sleep-style jump: real time advances well past the window while the old uptime source would not have.