That is also a misunderstanding. It all depends on the verifier. If the verifier implementation is correct then the prover cannot fool the verifier even the slightest bit. That is the magic of proof systems. The invention is that there is no trust required. The prover can only ever prove a valid chainstate. Otherwise, it isn't a valid proof.
Of course, you can doubt our implementation. And we openly state ourselves that this is all still prototype-grade. It's still a long way to get it production-ready, but the underlying math is sound and well-established in the research community. STARKs don't even require any novel cryptographic assumptions like many other ZKP systems. They rely only on collision-resistant hash functions*.
* In theory. Actually, we're using a STARK-friendly hash function for proof recursion, e.g. Pedersen hash. However, this also relies on nothing more fancy than assuming that dlogs are hard.
What does it mean for the verifier implementation to be "correct"?
If I have an incorrect verifier I can be fooled, therefore I trade off the ability to verify a completely valid blockchain for the assumption that your organization built a proper prover and verifier.