fix(startup): stop a throwing initializer from killing cold start

[bmc08gt]

Bugsnag 6a8f47a7b5ee91bed8ac6cac is a cold-start crash 123 ms into launch: NoSuchMethodError out of ProcessCameraProvider.getInstance(), thrown from CameraXInitializer.

CameraX 1.6.1's ContextUtil calls Context.getDeviceId() behind a bare Build.VERSION.SDK_INT >= 34 check. The reporting runtime claims API 34 — it also claims to be a Pixel 8 Pro, while listing cpuAbi: [x86_64, arm64-v8a] with binaryArch: arm64 — but its framework has no such method. No CameraX version guards against a runtime that lies about its API level, so the call site is not fixable upstream.

What made that fatal is ours. CameraXInitializer ran the warm-up in a bare CoroutineScope(Dispatchers.IO).launch { } with no handler, during ContentProvider creation, before any UI exists — so the throwable went straight to the default uncaught-exception handler and took the process with it. Three other initializers had the same shape. Wrapping the block in catch (e: Exception) would not have helped: NoSuchMethodError is a LinkageError, which extends Error.

So this adds one launchBestEffort helper that owns the pattern — catches Throwable, re-throws CancellationException so structured cancellation still works, and routes failures through trace() so they land in Bugsnag as handled errors instead of crashes. All four initializers (camerax, curves, clock, trace) now use it.

CameraXInitializer and DiscreteBondingCurveInitializer also gain TraceInitializer as a dependency. trace() early-returns until TraceManager.initialize has run, so without that edge a failure in either would be swallowed silently — the failure sink has to exist before the task that might need it.

Not covered here: CodeScanner.kt:283 calls getCameraProvider() unwrapped, so the same NoSuchMethodError can still surface when the scanner opens. That's a feature-level failure on a device that cannot run the camera anyway, not a launch crash, and it wants its own error path.