Probabilities are entirely the wrong model to reason about bugs in an adversarial environment.
We can't just cherry pick what to apply our arguments to. The entire argument here is entirely based around the probability that Bitcoin Core is
less likely to fork than alternatives, because the exact same logic you describe applies to multiple versions of Bitcoin Core on different compilers, OSes, hardware, etc, as much as it does to alternatives. Of course, in an adversarial environment, you have bad faith actors looking to exploit those probabilities. You're asserting that there is a much lower probability that they will be able to do so between two versions of Bitcoin Core. That's fair, but it doesn't make any sense to use probabilities to assert that and then turn around and say they don't matter when applied to a different implementation.
Either probabilities don't matter and the entire argument about whether Bitcoin Core is more or less likely (probability) to fork or not is moot, or they really do matter. I claim they absolutely do matter because Bitcoin Core isn't immune to forks either and there is clearly some chance involved that forks will occur between any two pieces of Bitcoin software.
But thinking that passing a prefab test suite that someone else wrote alone is sufficient-- which is certainly the impression given there-- sounds like magical thinking. It's not sufficient, merely necessary, and one shouldn't rely on it alone. (If this wasn't the message you were intending to convey, it wasn't clear to me.)
The claim isn't that a prefab test suite is entirely sufficient, it's that it lowers the probability of a fork occurring. When is the probability low enough that it's generally safe to transact? If you claim there isn't one, then Bitcoin, as a whole, is unsafe to transact on because the entirety of consensus is probability based to begin with.