fix(core): Order breadcrumbs by their own timestamp (JAVA-579)

[runningcode]

📜 Description

Breadcrumb.compareTo ordered breadcrumbs purely by a System.nanoTime() reading taken in the constructor. That reading is meaningful only for breadcrumbs created in the same process run, and two paths violate that:

• Deserialized breadcrumbs. Breadcrumb.fromMap and Breadcrumb.Deserializer both went through the public Breadcrumb(Date) constructor, so a breadcrumb read back from disk or handed over by a hybrid SDK gets a fresh tick at parse time. A breadcrumb recorded yesterday sorted as if it had just happened, and the order CombinedScopeView merges the three scopes into became parse order rather than recorded order.
• Clones. The copy constructor also took a fresh tick, so Scope's breadcrumb cloning moved every copied breadcrumb to the end of the order.

This orders by the recorded timestamp instead, keeping the creation tick as the tie-breaker it was added for in #3355. Timestamps are millisecond-granular, so breadcrumbs recorded within the same millisecond still resolve in the order they were actually recorded. A deserialized breadcrumb carries no tick (a tick from an earlier process run is a number from an unrelated origin, not a position in this run's order) and sorts purely by timestamp; a clone carries the original's tick and keeps its position.

SentryClient already re-sorts the final breadcrumb list by timestamp before sending, so this makes the scope-merge order agree with the order that actually ships — which matters for which breadcrumbs survive the maxBreadcrumbs cap during the merge.

💡 Motivation and Context

Audit finding §C7 from the clock-usage audit: a System.nanoTime() value was driving an ordering decision across a process boundary, where it carries no meaning.

• resolves: JAVA-579 (partially — §C7 breadcrumb ordering only)
• part of: Remaining low-priority clock issues and clock-step regression coverage #5582

💚 How did you test it?

Three unit tests in BreadcrumbTest.

📝 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.

Note for hybrid SDKs: breadcrumbs passed in via Breadcrumb.fromMap now sort by the timestamp they carry rather than by the moment they were handed over. That is the intended fix, but it does change the order hybrid breadcrumbs land in relative to native ones.

🔮 Next steps

[linear-code]

JAVA-579

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[adinauer]

We should always fill in creationTick as otherwise we risk a different bug.

[adinauer]

h I think we should fill in the creationTick here too. I'm worried about losing order on deserialization. The bug should still be fixed by preferring timestamp for the comparison and just using creationTick as tie breaker.