[Diagnostics] Add a brief summary to the documentation for several concurrency errors.

userdocs/diagnostics/actor-isolated-call.md

@@ -1,5 +1,7 @@
 # Calling an actor-isolated method from a synchronous nonisolated context
 
+Accessing actor-isolated state from outside the actor can cause data races in your program. Resolve this error by calling actor-isolated functions on the actor.
+
 Calls to actor-isolated methods from outside the actor must be done asynchronously. Otherwise, access to actor state can happen concurrently and lead to data races. These rules also apply to global actors like the main actor.
 
 For example:

userdocs/diagnostics/conformance-isolation.md

@@ -1,5 +1,7 @@
 # Protocol conformances crossing into actor-isolated code
 
+Protocol conformances crossing into actor-isolated code can cause data races in your program. Resolve this error by ensuring access to isolated state is always done within the actor.
+
 When a type conforms to a protocol, any generic code can perform operations on that type through the protocol. If the operations that the type used to satisfy the protocol requirements are actor-isolated, this may result in a diagnostic indicating that the conformance crosses into actor-isolated code. For example:
 
 ```swift

userdocs/diagnostics/error-in-future-swift-version.md

@@ -1,5 +1,7 @@
 # Language mode and tools version
 
+Swift language mode and Swift compiler tools version are distinct concepts. One compiler version can support multiple language modes.
+
 There are two related kinds of "Swift version" that are distinct:
 
 * Swift tools version: the version number of the compiler itself. For example, the Swift 5.6 compiler was introduced in March 2022.

userdocs/diagnostics/isolated-conformances.md

@@ -1,5 +1,7 @@
 # Isolated conformances
 
+Using an isolated conformance from outside the actor can cause data races in your program. Resolve these errors by only using isolated conformances within the actor.
+
 A protocol conformance can be isolated to a specific global actor, meaning that the conformance can only be used by code running on that actor. Isolated conformances are expressed by specifying the global actor on the conformance itself:
 
 ```swift

userdocs/diagnostics/mutable-global-variable.md

@@ -1,5 +1,7 @@
 # Unsafe mutable global and static variables
 
+Mutable global and static variables that can be accessed from anywhere can cause data races in your program. Resolve this error by making the state immutable or protecting it with a global actor.
+
 Concurrency checking prohibits mutable global and static variables that are `nonisolated` because they can be accessed from arbitrary concurrency domains at once and lead to data races.
 
 For example:

userdocs/diagnostics/sending-closure-risks-data-race.md

@@ -1,5 +1,7 @@
 # Sending closure risks causing data races
 
+Sharing mutable state between concurrent tasks can cause data races in your program. Resolve this error by only accessing mutable state in one task at a time.
+
 If a type does not conform to `Sendable`, the compiler enforces that each instance of that type is only accessed by one concurrency domain at a time. The compiler also prevents you from capturing values in closures that are sent to another concurrency domain if the value can be accessed from the original concurrency domain too.
 
 For example:

userdocs/diagnostics/sending-risks-data-race.md

@@ -1,5 +1,7 @@
 # Sending value risks causing data races
 
+Sharing mutable state between concurrent tasks can cause data races in your program. Resolve this error by only accessing mutable state in one task at a time.
+
 If a type does not conform to `Sendable` the compiler will enforce that each instance of that type is only accessed by one concurrency domain at a time. The `sending 'x' risks causing data races` error indicates that your code can access a non-`Sendable` value from multiple concurrency domains at once.
 
 For example, if a value can be accessed from the main actor, it's invalid to send the same instance to another concurrency domain while the main actor can still access it. This mistake is common when calling an `async` function on a class from the main actor: