Batch or defer scope-persistence disk writes during startup

[runningcode]

Problem

A customer cold-start Perfetto trace (customer build, Galaxy A14 / API 34, TTID 1723 ms, method-level tracing incl. io.sentry.*) shows the scope-persistence path is the single largest SDK cost during startup — bigger than init itself:

On the SentryExecutorService thread during the 1.7 s startup window (250 ms CPU total):

• io.sentry.cache.tape.FileObjectQueue#add × 107 = 460 ms wall
• io.sentry.cache.PersistingScopeObserver#store × 310 = 376 ms
• io.sentry.JsonSerializer#serialize × 421 = 172 ms
• PersistingScopeObserver$1#toStream × 107 = 94.6 ms

And on the main thread: Scopes#addBreadcrumb × 17 = 50 ms total with a single 24.2 ms call (9.3 ms inside PersistingScopeObserver#addBreadcrumb — suspected lazy FileObjectQueue init / inline write on the caller thread, see breadcrumbsQueue LazyEvaluator in sentry/src/main/java/io/sentry/cache/PersistingScopeObserver.java).

Every breadcrumb triggers serialize + a QueueFile disk write; apps that wrap network calls (OkHttp interceptor here) generate dozens of breadcrumbs during launch.

Proposal (investigate)

• Batch/coalesce breadcrumb persistence (flush every N adds or on an interval/idle) instead of one QueueFile write per breadcrumb.
• Defer persistence during the startup window (ties into the stagger-past-first-frame work) — the data is only needed if the process dies.
• Ensure the queue-file lazy init and any inline-write fallback never run on the caller/main thread.
• Re-measure maxBreadcrumbs-sized restore/write costs on low-end devices.

Notes

• Persistence exists for crash/ANR enrichment on next launch — batching trades a small data-loss window for startup CPU/IO; quantify before choosing flush granularity.
• Evidence: median.perfetto-trace (customer), analysis scratchpad median.perfetto-trace_analysis_v2.md.

[linear-code]

JAVA-628