build: switch to sentry-cocoa submodule for managed builds

[jpnurmi]

Allows building sentry-cocoa with SENTRY_CRASH_MANAGED_RUNTIME for eliminating duplicate native exceptions on iOS:

• fix: prevent redundant native exceptions on iOS #5126

Note: The old .properties -based release download is left intact to make it easy to switch back in the future if we ever get an official managed build variant...

#skip-changelog

[github-actions]

Semver Impact of This PR

⚪ None (no version bump detected)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

This PR will not appear in the changelog.

---

_{🤖 This preview updates automatically when you update the PR.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.99%. Comparing base (39ea4d8) to head (a1d84ac).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5131      +/-   ##
==========================================
- Coverage   74.12%   73.99%   -0.14%     
==========================================
  Files         499      499              
  Lines       18067    18067              
  Branches     3520     3520              
==========================================
- Hits        13392    13368      -24     
- Misses       3813     3839      +26     
+ Partials      862      860       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Deleted properties file still referenced in csproj fallback
  • Restored modules/sentry-cocoa.properties so the existing non-submodule fallback PropertyGroup can safely read version metadata again.

Or push these changes by commenting:

@cursor push f857a6ea73

Preview (f857a6ea73)

diff --git a/modules/sentry-cocoa.properties b/modules/sentry-cocoa.properties
new file mode 100644
--- /dev/null
+++ b/modules/sentry-cocoa.properties
@@ -1,0 +1,2 @@
+version = 9.8.0
+repo = https://github.com/getsentry/sentry-cocoa

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5c69a43. Configure here.}

[sentry-warden]

TOCTOU race condition in stale lock cleanup allows concurrent builds

The stale PID detection logic (lines 13-17) has a time-of-check-to-time-of-use race condition. When multiple processes detect that the PID file contains a dead process, they can all call rm -f "$PID_FILE" simultaneously, then all proceed to acquire the lock. The set -C noclobber only protects against concurrent file creation, not against the stale-detection-then-delete sequence. This defeats the locking mechanism's purpose of serializing xcodebuild invocations to prevent DerivedData races.

Verification

Read the complete script (lines 1-90). Traced the locking logic: set -C; echo $ > $PID_FILE is atomic for creation, but lines 13-17 perform non-atomic check-then-delete. Two concurrent processes can both: (1) fail to acquire lock, (2) read stale PID, (3) verify process is dead, (4) both delete file, (5) both succeed on next loop iteration.

Suggested fix: Use flock for proper file locking, or use an atomic mkdir-based lock instead of PID file with stale detection

Suggested change

	while ! (set -C; echo $$ > "$PID_FILE") 2>/dev/null; do
	build_pid=$(cat "$PID_FILE" 2>/dev/null || true)
	if [[ -n "$build_pid" ]] && ! kill -0 "$build_pid" 2>/dev/null; then
	echo "Previous build did not complete (pid $build_pid); cleaning up and retrying" >&2
	rm -f "$PID_FILE"
	continue
	fi
	sleep 2
	done
	LOCK_FILE="$PWD/Carthage/.build.lock"
	exec 9>"$LOCK_FILE"
	trap 'rm -f "$LOCK_FILE"' EXIT
	flock 9

Identified by Warden find-bugs · WD6-SAJ