Minor corrections to Trigger guide

Mostly fixes typos and improves the formatting such that the formatting on the validation.md page is a bit more legible in both light & dark mode (using more neutral shades).

A couple of slightly more substantial additions on combohypo.md. @tamartin, would you agree with the phrasing on the jet steps, and on the 2-body variable calculations?

There were a couple of other questions I had:

1. On the top level page, we link to runHLT in 24.0 but many other places point to main. To be consistent, should we link 24.0 to point to production code or main for future-proofing?
2. Not sure if this change on combohypo.md is correct (L90):

If the feature is itself and ^an RoI, and that RoI is flagged as full-scan.

3. On monitoring.md, we have the cryptic phrase

* __all__ variables computed by reconstruction and hypo algorithms (not tools) and __monitored__ should be monitored.

This looks like __monitored__ should be replaced with something, or omitted.

docs/athena/trigger/algos.md

@@ -6,13 +6,13 @@ in the precision reconstruction step, whereas trigger specific ones are used in
 initial fast reconstruction step. An important difference in the trigger use-case is that the
 reconstruction algorithms are executed only if needed. This is done by embedding them between
 filter algorithms (control flow) that ensure that algorithms are only executed if the preceding
-steps passed. Other difference is that the algorithm instances may be executed multiple times per event in EventViews (briefly mentioned later).
+steps passed. Another difference is that the algorithm instances may be executed multiple times per event in EventViews (briefly mentioned later).
 
 
 ## Features of reconstruction algorithms
 1. It is required that the algorithms used by HLT are reentrant, that is inherited from `AthReentrantAlgorithm`.
   In practice this means that the `execute` method does not modify any state variable of the algorithm itself.
-1. The I/O of data items needed by the algorithm is done identically as in offline case and is documented here 
+1. The I/O of data items needed by the algorithm is done identically as in the offline case and is documented here
    [MultiThreadingEventDataAccess](https://twiki.cern.ch/twiki/bin/view/AtlasComputing/MultiThreadingEventDataAccessV2).
 1. Access to conditions data needs to be migrated following 
    [MultiThreadingConditionsAccess](https://twiki.cern.ch/twiki/bin/view/AtlasComputing/MultiThreadingConditionsAccess)