Read epoch instants from EpochClock instead of CurrentDateProvider #6583

Several internal call sites use CurrentDateProvider only to read the current epoch time. options.getEpochClock() gives the same value. Moving them now changes nothing that is sent, and it shrinks what v9 has to change when it removes ICurrentDateProvider (#6506).

Call sites

• AnrV2Integration and TombstoneIntegration pass the provider to ApplicationExitInfoHistoryDispatcher, which computes the 90-day cutoff for ApplicationExitInfo timestamps.
• MemoryLimiterIntegration passes it to the same dispatcher.
• SentryOkHttpInterceptor and SentryOkHttpEvent stamp HTTP_START_TIMESTAMP and HTTP_END_TIMESTAMP for replay network details.

Each one compares against or sends an epoch instant, so each has to stay on the wall clock. EpochClock is the wall clock. On Android it reads System.currentTimeMillis(). On Java 9+ it reads Instant, which gives the same millisecond.

None of this is public API. The integrations' constructors that take an ICurrentDateProvider are package-private and only used by tests.

Out of scope

• LifecycleWatcher: already moved on 9.x.x by fix(android): Decide session rotation on a monotonic clock (JAVA-573) #6096. Changing it on main would only cause a conflict.
• RateLimiter and ReplayIntegration: their ICurrentDateProvider constructors are public API, so they change in v9 (Breaking clock changes for v9: span timing and ICurrentDateProvider removal #6506).
• Debouncer and AndroidEnvelopeCache: Clean up the remaining AndroidCurrentDateProvider usages #6104.
• The replay capture strategies: Session Replay segment, buffer and gesture timestamps read the wall clock #6522.

Done when

• None of the call sites above references CurrentDateProvider.
• Tests inject a fake EpochClock.
• No .api diff and no changelog entry, because nothing users can see changes.