perf(android): Init shake detector off the main thread (#5784)

* perf(android): Init shake detector off the main thread (JAVA-618)

FeedbackShakeIntegration.register() resolved the accelerometer via
SensorManager synchronously on the calling thread, which under auto-init
is the main thread. On a Pixel 10 this first SensorManager access
measured ~1.75ms, making it the single most expensive integration in the
Sentry.init register loop.

Submit the pre-warm init() to the executor service instead. start()
already re-runs the idempotent init() on demand, so shake detection still
works if an activity resumes before the warm-up completes. SentryShakeDetector's
lifecycle methods are now synchronized so the executor warm-up and a
main-thread start() cannot race on the sensor fields.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: Add changelog for shake-detector init off main thread (JAVA-618)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(android): Guard shake detector against warm-up after close (JAVA-618)

A warm-up init submitted to the executor could be drained after the
integration's close() ran, since integrations shut down before the
executor. That re-resolved the sensor and leaked a HandlerThread. Guard
init()/start() with a closed latch so a late warm-up is a no-op.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(android): Re-arm shake detector on re-register (JAVA-618)

The closed latch added to neutralize a warm-up drained after close()
was permanent, so re-registering the same integration (e.g. a second
Sentry.init reusing the same options) left shake detection off with no
recovery. register() now re-arms the detector via reopen(), which the
stale-warm-up path (init()) deliberately does not, preserving the
drain-after-close guard.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>