Remaining low-priority clock issues and clock-step regression coverage

Tracking issue for the remaining low-priority audit findings, plus the project-wide regression sweep. Split any item into its own issue if it grows.

**Regression coverage:** unit tests already inject `ICurrentDateProvider` fakes everywhere. This project should add cases simulating backward/forward clock steps and deep-sleep delays across the affected paths (tracer, session, replay, check-in) so the fixes are covered and future regressions are caught.

**Remaining low-priority findings (audit §C4–C7, all LOW):**

* **C4 — App-start anchor projection.** `TimeSpan` (uptime + wall anchor) captures the wall anchor once; `setStartedAt()` back-projects assuming no step since process start → NTP sync shortly after boot shifts app-start span timestamps relative to later-anchored spans.
* **C5 —** `SpanFrameMetricsCollector.toNanoTime()`**.** Re-anchors wall-based `SentryLongDate`s into the `nanoTime` base using the current offset; wrong by any step since the date was created, and across deep sleep → frames attributed to the wrong span windows.
* **C6 — Wall-clock TTLs/cleanup.** `HostnameCache` 5h TTL; `Sentry.classCreationTimestamp` vs `File.lastModified()` for profiling-traces cleanup; `CacheStrategy` envelope rotation ordered by `lastModified()`; `DefaultCompositePerformanceCollector` 30s auto-stop via wall diff + sampling on `java.util.Timer`.
* **C7 — Informational.** `Breadcrumb.compareTo` orders by captured `System.nanoTime()` (restored-from-disk breadcrumbs get fresh nanos at parse → cross-restart ordering is parse-order); cross-type `SentryDate` arithmetic (`SentryNanotimeDate` vs `SentryLongDate`) silently degrades to ms-precision wall math.

Source: [JAVA-557]() §C4–C7 + "Verification idea".