chore: Add tracking for feature flags

[denrase]

#skip-changelog

📜 Description

Track runtime use of the manual feature flag APIs by adding featureFlags to sdk.features after the API is used.

Runtime-discovered feature flag usage is stored internally and thread-safely on the active SDK options, then merged with the existing option-derived features when SDK metadata is built.

💡 Motivation and Context

We want internal telemetry showing actual feature flag API adoption, matching the behavior in sentry-flutter. Inferring this at SDK initialization is not possible because feature flags are enabled through runtime API usage.

Closes #8594

💚 How did you test it?

• Added tests for storage, concurrency, SDK metadata generation, and the SDK/Hub feature flag entry points.
• Manually used Add Scope Flag in the iOS Swift sample, captured an event, and confirmed featureFlags appears in the event's sdk.features JSON.
• Link to Sentry: https://sentry-sdks.sentry.io/issues/6607086585/events/latest/?project=5428557&query=is%3Aunresolved&referrer=latest-event

📝 Checklist

• 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]

📲 Install Builds

iOS

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

⚙️ sentry-cocoa Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1215.42 ms	1254.00 ms	38.58 ms
Size	24.14 KiB	1.27 MiB	1.25 MiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
df67624	1225.12 ms	1259.90 ms	34.78 ms
6e35062	1232.19 ms	1262.91 ms	30.73 ms
220d7ef	1238.77 ms	1267.42 ms	28.65 ms
4b5a1d7	1235.27 ms	1264.49 ms	29.22 ms
9319185	1223.24 ms	1249.98 ms	26.73 ms
d0b52d1	1227.31 ms	1258.32 ms	31.01 ms
b6b0d1d	1236.69 ms	1270.22 ms	33.52 ms
5b1c31e	1221.35 ms	1246.14 ms	24.79 ms
9787f05	1233.67 ms	1269.00 ms	35.33 ms
29d1b7f	1220.58 ms	1254.14 ms	33.56 ms

App size

Revision	Plain	With Sentry	Diff
df67624	24.14 KiB	1.14 MiB	1.12 MiB
6e35062	24.14 KiB	1.22 MiB	1.20 MiB
220d7ef	24.14 KiB	1.17 MiB	1.14 MiB
4b5a1d7	24.14 KiB	1.22 MiB	1.20 MiB
9319185	24.14 KiB	1.16 MiB	1.13 MiB
d0b52d1	24.14 KiB	1.15 MiB	1.13 MiB
b6b0d1d	24.14 KiB	1.18 MiB	1.16 MiB
5b1c31e	24.14 KiB	1.24 MiB	1.22 MiB
9787f05	24.14 KiB	1.18 MiB	1.15 MiB
29d1b7f	24.14 KiB	1.26 MiB	1.23 MiB

Previous results on branch: chore/add-tracking-for-feature-flags

Startup times

Revision	Plain	With Sentry	Diff
bbe0e31	1227.21 ms	1260.16 ms	32.95 ms

App size

Revision	Plain	With Sentry	Diff
bbe0e31	24.14 KiB	1.27 MiB	1.24 MiB

[itaybre]

This seems a bit over engineered, at this moment I believe a simple boolean flag would be simpler and if we end up with other features like this we can build the set logic

[denrase]

@itaybre Thought I add something generic as we track multiple runtime values in flutter and it's easy to query this data, but we can also do it simpy and then expand if needed.