Every client entity is built with CSOT `timeoutMS` (OP_TIMEOUT_MS, 10 s), and
CSOT overwrites `maxTimeMS` on each command with what is left of that budget.
An expectation of `maxTimeMS: 6000` therefore meets the harness's 10000, and
no amount of engine correctness would change it. Reported unsupported rather
than failed: a FAIL is a claim about the engine, and this is a claim about the
runner.
Refused unconditionally when an expected command mentions `maxTimeMS`, not
only when the two values differ, so it can never become a pass by coincidence.
Exactly one case in the corpus asserts it -- estimatedDocumentCount.json,
"estimatedDocumentCount with maxTimeMS" -- so the whole cost of the hatch is
one case, which is why it is worth taking instead of dropping `timeoutMS`.
That option is not open anyway: `timeoutMS` is what replaced the outer race
that once turned ~190 good cases into phantom timeout FAILs.
This is the only escape hatch in the runner. Everything else is either an
honest FAIL or an enumerated unsupported feature.
159/133/195 becomes 159/132/196: one case, fail to skip, and nothing else
moves.
54ad124c18