Fix typos and improve clarity in docs

Author: Rastaban

docs/code-quality/c26132.md

@@ -13,7 +13,7 @@ ms.date:     02/11/2025
 
 The analyzer issues Warning C26132 when it detects that a lock, which is annotated to protect a value, isn't held while accessing the value. However, a related lock is held. The code may be thread-safe, so you might need to update the annotations.
 
-This diagnostic usually does not indicate a bug in the code, but rather a mismatch between the annotations and the actual locking behavior. If this is the case, the diagnostic should be resolved as there may be other static analysis issues that are not being reported due to the inconsistant annotations.
+This diagnostic usually doesn't indicate a bug in the code, but rather a mismatch between the annotations and the actual locking behavior. If so, the diagnostic should be resolved as there may be other static analysis issues that aren't being reported due to the inconsistent annotations.
 
 ## Examples
 
@@ -45,7 +45,7 @@ void Initialize(_Guarded_by_(customLock01) int* data)
 }
 ```
 
-In this example, the `Initialize` function is thread-safe and behaves as designed, but that design isn't correctly reflected in the concurrency SAL annotations. Fix by adjusting the annotations on the custom locking functions to use `criticalSection` rather than `criticalSection->cs`. This could also be fixed by changing the `_Guarded_by_` annotation from `customLock01` to `customLock01.cs`.
+In this example, the `Initialize` function is thread-safe and behaves as designed, but that design isn't correctly reflected in the concurrency SAL annotations. Fix by adjusting the annotations on the custom locking functions to use `criticalSection` rather than `criticalSection->cs`. The warning could also be fixed by changing the `_Guarded_by_` annotation from `customLock01` to `customLock01.cs`.
 
 ```cpp
 #include <sal.h>

docs/code-quality/c26133.md

@@ -13,7 +13,7 @@ ms.date:     02/19/2025
 
 Warning C26133 is issued when the analyzer detects that the lock required to call a function isn't held when the function is called. However, another lock that appears to be related is held. It's possible the code is thread-safe, and the annotations need to be updated.
 
-This diagnostic usually does not indicate a bug in the code, but rather a mismatch between the annotations and the actual locking behavior. If this is the case, the diagnostic should be resolved as there may be other static analysis issues that are not being reported due to the inconsistant annotations.
+This diagnostic usually doesn't indicate a bug in the code, but rather a mismatch between the annotations and the actual locking behavior. If so, the diagnostic should be resolved as there may be other static analysis issues that aren't being reported due to the inconsistent annotations.
 
 ## Examples
 
@@ -47,7 +47,7 @@ void DoTask()
 }
 ```
 
-In this example, the `DoTask` function is thread-safe and behaves as designed, but that design isn't correctly reflected in the concurrency SAL annotations. Fix by adjusting the annotations on the custom locking functions to use `criticalSection` rather than `criticalSection->cs`. This could also be fixed by changing the `_Requires_lock_held_` annotation from `customLock01` to `customLock01.cs`.
+In this example, the `DoTask` function is thread-safe and behaves as designed, but that design isn't correctly reflected in the concurrency SAL annotations. Fix by adjusting the annotations on the custom locking functions to use `criticalSection` rather than `criticalSection->cs`. The warning could also be fixed by changing the `_Requires_lock_held_` annotation from `customLock01` to `customLock01.cs`.
 
 ```cpp
 #include <sal.h>