Turn repeated thread locality content into an include

docs/platforms/dotnet/common/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/powershell/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

docs/platforms/unity/enriching-events/scopes/index.mdx

@@ -34,24 +34,7 @@ other hand are more user facing. You can call <PlatformIdentifier name="configur
 time to modify data stored on the scope. This is useful for doing things like
 [modifying the context](../context/).
 
-<Alert>
-
-If you are very curious about how thread locality works for scope data, in .NET there
-are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
-most appropriate mode for your application type. However this can be overridden by
-setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
-
-If global mode is disabled (appropriate for most server based applications), the
-ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
-context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
-explains that concept in more detail.
-
-If global mode is enabled (appropriate for desktop applications), ambient scope data is
-stored as a Singleton and available globally. This means you can set context (such as
-the user logged into the application) once and it will be sent with all events, regardless
-of whether the event was captured on the UI thread or a background thread.
-
-</Alert>
+<Include name="platforms/configuration/options/thread-locality.mdx" />
 
 When you call a global function such as <PlatformIdentifier name="capture-event" /> internally Sentry
 discovers the current hub and asks it to capture an event. Internally the hub will

includes/platforms/configuration/options/thread-locality.mdx

@@ -0,0 +1,18 @@
+<Alert>
+
+If you are curious about how thread locality works for scope data, in .NET, there
+are two modes for managing "ambient data". Usuaully Sentry will automatically choose the
+most appropriate mode for your application type, however this can be overridden by
+setting [`SentryOptions.IsGlobalModeEnabled`](../../configuration/options/#is-global-mode-enabled) manually.
+
+If global mode is disabled (appropriate for most server-based applications), the
+ambient scope data is stored as an `AsyncLocal` and so it will flow with the execution
+context. Stephen Toub's blog post on [ExecutionContext vs SynchronizationContext](https://devblogs.microsoft.com/pfxteam/executioncontext-vs-synchronizationcontext/)
+explains that concept in more detail.
+
+If global mode is enabled (appropriate for desktop applications), ambient scope data is
+stored as a Singleton and available globally. This means you can set context (such as
+the user logged into the application) once and it will be sent with all events, regardless
+of whether the event was captured on the UI thread or a background thread.
+
+</Alert>