build: gate Cocoa bindings regeneration on a stamp file

[ric-oliv]

TL;DR: Objective Sharpie writes ApiDefinition.cs before patch-cocoa-bindings.cs makes it valid C#, so the generated files can't gate their own regeneration.

Problem

The macOS build fails intermittently on main with invalid C# in the generated
Cocoa bindings (failing run):

ApiDefinition.cs(1860,9): error CS1519: Invalid token '"In the next major version, the hint parameter will be added to "'

SentryObjCOptions.h declares beforeSendWithHint / beforeBreadcrumbWithHint with
DEPRECATED_MSG_ATTRIBUTE messages split across adjacent ObjC string literals — legal in C,
a syntax error in C#. scripts/patch-cocoa-bindings.cs joins them back together.

_GenerateSentryCocoaBindings used the generated files as its Outputs, but they're produced
in two stages: Objective Sharpie writes ApiDefinition.cs, and the patch script makes it valid
C# ~20s later. The incremental check went up-to-date at the end of stage one.

Sentry.Bindings.Cocoa builds in three configurations (the two inner TFMs plus the
cross-targeting outer build). In the failing run one of them sampled the timestamps inside that
window, logged Skipping target "_GenerateSentryCocoaBindings" because all output files are up-to-date, and compiled the unpatched output:

08:34:06 sharpie finishes — unpatched ApiDefinition.cs on disk
08:34:15 other instance: "Skipping target ... up-to-date"
08:34:17 CS1519 x8
08:34:21 Patching .../ApiDefinition.cs

This was latent in the two-stage generation. It became reachable in #5594, which removed a
non-existent Carthage/Headers/**/*.h glob from Inputs; while that phantom path was there the
target ran every time, so every instance went through the TargetFramework=once request and was
serialised behind it.

Fix

Gate the check on a stamp touched only after generation and patching complete, so a late
instance blocks on the in-flight TargetFramework=once request instead of skipping past it. The
generated files stay in Outputs, so deleting one still forces regeneration.

Same pattern as _SetGeneratedSupportDelegatesInternal below it, and as
build-sentry-cocoa.sh, which writes Carthage/.built-from-sha last for this reason.

Verification

Reproduced locally by adding a delay between Sharpie and the patch step and building the project
in two configurations with the second starting inside the window — identical failure, same
errors and line numbers. With the fix, the second instance waits for the generation and the build
succeeds:

11:29:31 leader _GenerateSentryCocoaBindings "Building target completely"
11:30:16 follower _GenerateSentryCocoaBindings "Building target completely" <- not skipped
11:31:04 leader generation done
11:31:04 follower _InnerGenerateSentryCocoaBindings "Previously built successfully"

Unfixed, under the race	8 errors, reproduces CI exactly
Fixed, same race	0 errors, follower blocked 48s
Nothing changed	no regeneration (#5594 behaviour preserved)
Stamp / generated file deleted, input touched	regenerates in all three
Fresh obj/	builds, stamp created
Full Sentry-CI-Build-macOS.slnf	both Cocoa TFMs built, one generation
Generated files after repeated regeneration	byte-identical to main

obj/ is gitignored, so the stamp isn't committed.

#skip-changelog

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.83%. Comparing base (54bb628) to head (9db7a46).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5598      +/-   ##
==========================================
+ Coverage   74.81%   74.83%   +0.02%     
==========================================
  Files         515      515              
  Lines       18963    18963              
  Branches     3694     3694              
==========================================
+ Hits        14187    14191       +4     
+ Misses       3894     3893       -1     
+ Partials      882      879       -3     

☔ View full report in Codecov by Harness.
📢 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.

[jamescrosswell]

Nice - thanks @ric-oliv !

[jamescrosswell]

Nice - thanks @ric-oliv