Your question explicitly assumes that QA must be 100% infallible in order to be useful. This is incorrect, and I'm afraid shows that you have seriously misunderstood the purpose of QA.
Because even the QA could have made mistakes.
Of course they could. Good practise is to consider reviewing and testing as equally prone to errors. As a result, you do not blindly make changes proposed by a reviewer, and you do not blindly make changes to make your tests pass, because both could be wrong.
The purpose of QA is to provide defence in depth. The more eyes on a problem, the better it'll be tested. The original designer is generally too invested in the design to see outside the box and will tend to test against what they know it does, whereas an independent engineer can approach it as a black box and test against the requirements without preconceptions. This can also expose issues with ambiguous requirements, where both the designer and tester can be "right" for their interpretation, but still come up with conflicting results.
It is not possible for QA to guarantee that there are no bugs in the code. Be clear that it is not just impractical, it is actually mathematically impossible. (Read up on the halting problem if you want proof.) What QA can do is run a reasonable set of tests which will exercise the code over a reasonable range of operating conditions. The more detailed the tests are, the more likely they are to find any remaining bugs, but also the more they cost. Development standards such as DO-178B often mandate the level of testing required depending on the safety-related nature of software.
In the 1980s and 1990s there was a significant drive from academia to use formal specification, in the belief that the process of turning designs into code was a significant source of errors. A formal specification language/process was intended to allow test cases to be generated which would be unambiguously correct, and hence could be used to validate the possibly-faulty code in the way you seem to want. As you can probably see (but apparently Computer Science "experts" at the time couldn't), the formal specification therefore became a second implementation of the requirements and as such was equally prone to contain errors in its implementation. Industry discovered that in fact the process of coding was relatively robust, and normal QA processes were substantially likely to pick up coding bugs. Most serious problems turned out instead to be related to incorrect or ambiguous requirements, which inherently cannot be solved through any technical process. Most people involved in the formal specification field at that time acknowledge in hindsight that it was a dead end.
And as a step beyond QA... Some safety-related systems use redundancy where two (or more) control systems are produced by independent non-communicating teams. All steps from design to QA are carried out separately for each system. Whilst both systems may still contain bugs, they are extremely unlikely to both contain the same bug, so a situation which causes one controller to misbehave will not affect the other controller(s). Whether the fault is due to a coding bug or a different interpretation of requirements, one controller will still be operating correctly, and the system as a whole is designed to ensure safe operation in the event of this happening. This illustrates another principle of safety engineering - assume that the fault will occur, and figure out how to make the system as a whole robust to that fault wherever reasonably possible.