Just a littel cleanup in STM-code

_drafts/2024-12-26-STM-code.md

@@ -729,7 +729,7 @@ First, we don't try to barge unless we have been around for a while.  A little p
     member private _.bargeTimeElapsed = (int64 Environment.TickCount) - startTime > BargeWaitTicks
 ```
 
-Second, we only barge the other transaction if we are older.  This compares start points instead of read points, so this dates back to the first attempts of each transaction, not the current retry of each.  (To determine who is older, look at dates of birth, not who had the most recent birthday.)  The `compareAndSet` uses an `Interlocked` method.  Why might this fail?  The other transaction was running just before we got here.  Well, someone else may have barged it, or it may already be committing or have committed or somehow gotten aborted.  In those cases, even if it might be okay to proceed, it's too hard to tell, so let's just retry (via the block-and-bail that will follow).  If we do barge, we trigger the latch on the other transaction's `LTInfo` on our way out.  More on this in a minute (actually, 100 milliseconds).
+Second, we only barge the other transaction if we are older.  This compares start points instead of read points, so this dates back to the first attempts of each transaction, not the current retry of each.  (To determine who is older, look at dates of birth, not who had the most recent birthday.)  The `compareAndSet` uses an `Interlocked` method.  Why might this fail?  The other transaction was running just before we got here.  But from then now until now, someone else may have barged it, or it may already be committing or have committed or somehow gotten aborted.  In those cases, even if it might be okay to proceed, it's too hard to tell, so let's just retry (via the block-and-bail that will follow a failed barge attempt).  If we do barge, we trigger the latch on the other transaction's `LTInfo` on our way out.  More on this in a minute (actually, 100 milliseconds).
 
 The block-and-bail operation is short:
 
@@ -763,8 +763,8 @@ The `stop` call does some cleanup to get us ready for the a retry.:
 
  Next we wait (at least for a little bit) for the other transaction's latch to count down.
  Why wait?  We just decided to block-and-bail. This only happens when we've run into a conflict and we've lost the battle.
- If we just barreled through and started our retry immediately, the other transaction might not have had time to finish and quit running (either completely or that iteration) -- we'd just get locked again.  Why not just wait?  Why is the latch involved?
- Well, if the other transaction gets barged or if it transitions itself to a new state (this happens in `stop`), the latch will count down.  That can release us to proceed more quickly than `LockWaitMsecs`.
+ If we just barreled through and started our retry immediately, the other transaction might not have had time to finish and quit running (either completely or just its current iteration) -- we'd just get locked again.  Why not just wait?  Why is the latch involved?
+ Well, if the other transaction gets barged or if it transitions itself to a new state (this happens in `stop`), the latch will count down.  That can release us to proceed more quickly than the full `LockWaitMsecs`.
 
 ### Do not fear commitment