[bitsandfoxes]

The integration test app now enables app-hang tracking only when it runs the App Hang test, so a slow device can no longer send a hang event during the other tests.

Before, the test app enabled app-hang tracking with a 2 s timeout for every test. On a slow simulator, sentry-cocoa reported an App Hang Non Fully Blocked event (mechanism.type = AppHang, level error) about a second before the forced crash. The crash tag was already on the scope by then, so Sentry got two events for the tag. The Crash Capture lookup expects exactly one: it polled for the full 300 s and failed with "Expected 1, but got 2", and the job had to be rerun. In 30 days, Sentry received 15 of these hang events tagged with a crash ID, all from iOS. This was the most common test flake in the CI analysis: 13 failed Run iOS jobs in the window that still has logs.

How it works:

• IntegrationOptionsConfiguration sets EnableAppHangTracking only when the test argument is app-hang-capture. It reads the argument through IntegrationTester.GetTestArg, now internal, the same per-platform reader Start uses (iOS Objective-C helper, Android intent extra, desktop command line, WebGL query string; null in the Editor).
• The value that counts is the runtime one. The tests use Runtime native init on Android and iOS, so sentry-java (setEnableNdkAppHangTracking), sentry-cocoa and sentry-native all read it at SDK init. The build-time manifest and native options values aren't used.
• The App Hang tests (Desktop and Android) still run with tracking on and the 2 s timeout. No other test asserts anything about app hangs.

An earlier version of this PR filtered the hang event out of the lookup with a new -Filter on app-runner's Get-SentryTestEvent (getsentry/app-runner#63). That PR is closed. Stopping the hang event from being sent removes the cause on every platform, and the modules/app-runner pin stays where main has it.

CI: run 40863159412 on this head.

🤖 Generated with Claude Code