The only thing PR's lack in that regard is that if the reviewer accepts it then it gets added automatically, while ideally you should re review things after the reviewer has accepted it. That way they wont accidentally accept prototype changes.

The tool does not stop you from working in the way you suggest. Maybe it's not what the engineers who wrote it originally envisioned, but it's both simple and easy to work in the way you suggest.

The guy who couldn't take feedback (person A) had code merged in that wasn't properly tested. Person B said, "hey A. I could use some help. We wrote some tests around $feature that were missing and the tests show the feature doesn't work. We see $unexpected results. Wanna make sure we agree on how this should work."

Person A: no, it works, I tested it.

B: could you help us identify the flaw in the tests then - they seem rock solid.

A: no, my code works.

B: ... ok, can you join us and talk through it?

A: no, it works.

A was removed from the team after management came in and A continued to not acknowledge his code could be wrong.

This was aberrational. We, as an org and as a team, constantly strove to keep the focus on the quality of the code. And, yes, his code was borked.

Yeah I really hate those pesky automated linters running in standardised environments telling me I’ve screwed something up.

(/sarcasm, hopefully clearly!)

It's the bare minimum of professionalism.

If you are unable to separate feedback on your work, from attacks on your person, you are lacking some fairly fundamental skills needed for professional engineering.