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.