[supervacuus]

📜 Description

This PR further improves on the data collected when an iOS CrashE2E app does not exit:

• it replaces the 8s sample watchdog with kernel stackshots from spindump
• all partial reports, record collection or authorization failures are kept for upload
• collection and symbolication get a "requested" 60s budget (not a guaranteed hard deadline, so CI ensures
  the outer time limit)
• the collector requires non-interactive sudo
• adds an opt-in E2E scenario that deliberately keeps the SDK-loaded app running and is only used for testing the test harness in the context of app runs that don't terminate
• a Swift integration test verifies that the "normal timeout" of the above scenario:
  • collects readable stacks,
  • confirms the app has stopped during cleanup, and
  • --keep-going successfully runs the next scenario(!)
• CI runs the above for both reporters and keeps all logs even when the test passes
• improves the stopped-state handling by accepting a simulator-confirmed stop even when no previous process ID is
  available (also added tests for this)

💡 Motivation and Context

While last week's changes (#9345) improved the CrashE2E failure rate quite a bit, a couple of recent iOS CrashE2E timeouts were hard to investigate because the diagnostic command sample stopped after eight seconds, sometimes while processing symbols, without saving usable stacks.

I simply wanted the next failure to tell us what the app-under-test was doing. Passing ordinary crash scenarios in CI also did not prove that timeout diagnostics and cleanup worked, so this change tests that path explicitly.

This improves the harness and its diagnostics, should help us reduce the CrashE2E failure rate even further, and is essential preparation for #8855.

💚 How did you test it?

Ran the CrashE2E tests and the tests that test the harness lots of times :)

Also successfully ran the live timeout tests in experimental CI runs.

📝 Checklist

You have to check all boxes before merging:

• 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.
• If I added a new public API, I also added it to the SentryObjC wrapper.

[sentry]

Size Analysis

1 component analyzed

iOS Builds

Name	Configuration	Version	Download Size	Install Size
SDK-Size (iOS) io.sentry.sample.SDK-Size	Release	9.31.0 (1)	1.2 MB (+22 B)	3.1 MB (0 B)

Configure sentry-cocoa status check rules

[sentry]

📲 Install Builds

iOS

🔗 App Name	App ID	Version	Configuration
SDK-Size	io.sentry.sample.SDK-Size	9.31.0 (1)	Release

⚙️ sentry-cocoa Build Distribution Settings

[itaybre]

LGTM, very samll comments

[github-actions]

🚨 Detected changes in high risk code 🚨

High-risk code can easily blow up and is hard to test. We had severe bugs in the past. Be extra careful when changing these files, and have an extra careful look at these:

• .github/file-filters.yml