docs(telemetry): drop pre-squash comparisons from the workload harness comments

Three harness comments described the behaviour this change replaced, which the
squash merge does not publish.

- run-full-validation.sh: the capture flag means CAPTURE_EXIT is not the only
  record of capture health; and a gated capture failure is an infrastructure
  error, stated without 'exactly as before'.
- tx_submitter.py: give the reason the first occurrence logs at WARNING (DEBUG
  is off in CI) rather than what a failed run 'previously produced'.
- workload_orchestrator.py: a wedged process cannot stall the profile, rather
  than 'can no longer'.

Comments only, no behaviour change.

docker/telemetry/workload/run-full-validation.sh

@@ -964,7 +964,7 @@ fold_exit "$VALIDATION_EXIT"
 # were never measured. The messages below say incomplete, never missing.
 #
 # That thin file also says so itself, in the "capture" block capture_timings.py
-# writes into it, so the CAPTURE_EXIT below is no longer the only record of the
+# writes into it, so the CAPTURE_EXIT below is not the only record of the
 # capture's health: both paste-me paths read the flag and withhold the JSON
 # rather than offering an artifact this run has already called unusable.
 #
@@ -972,7 +972,7 @@ fold_exit "$VALIDATION_EXIT"
 # exploration), and with it out of the gate's verdict: a capture failure is
 # reported loudly and shown in the step-status table, but does not fail a run
 # whose caller asked not to be gated. With the gate active, a capture failure is
-# an infrastructure error (exit 2) exactly as before.
+# an infrastructure error (exit 2).
 #
 # When the comparison does run it either prints the paste-me JSON for a
 # placeholder baseline, or enforces thresholds and fails the run on regression.

docker/telemetry/workload/tx_submitter.py

@@ -787,10 +787,10 @@ async def submit_transaction(
 
         if not success:
             # First occurrence of each distinct result at WARNING, the rest at
-            # DEBUG. A run where every transaction failed previously produced
-            # no diagnostics at all, because DEBUG is off in CI; logging every
-            # failure instead would bury the run in thousands of identical
-            # lines.
+            # DEBUG. DEBUG is off in CI, so a run where every transaction fails
+            # would otherwise produce no diagnostics at all; logging every
+            # failure at WARNING instead would bury the run in thousands of
+            # identical lines.
             _log_first_failure(
                 "result:%s" % engine_result,
                 "%s result: %s (%s)",

docker/telemetry/workload/workload_orchestrator.py

@@ -59,7 +59,7 @@ PROFILES_FILE = SCRIPT_DIR / "workload-profiles.json"
 # trips) and then waits a fixed 10s for those funding transactions to
 # validate, and both generators drain in-flight requests while shutting down.
 # A generator that outruns this is killed and the phase records the timeout as
-# an error, so one wedged process can no longer stall the whole profile.
+# an error, so one wedged process cannot stall the whole profile.
 SUBPROCESS_GRACE_SEC = 90.0
 
 # How long to keep reading a killed process's output before giving up on it.