Now, you compile your code with this compiler, and if your own build reproducibly has the same results as this verified compiler, you're safe.
My solution even protects me from attacks where the source of the minifier is safe, and only the minified minifier contains the bug.
You are thinking of another kind of backdoor than the one being discussed. The backdooring technique being discussed relies on a compiler bug hidden in plain sight in the compiler's source code. It has not been sneaked into the binary with a “trusting trust”-like technique. The bug is just an ordinary compiler bug, you do not need to be the one who put it there, it can be a known, published bug and have already been fixed in the compiler's development version (although you can also have found the compiler bug yourself and have omitted to report it for maximum sneakiness).
Re-compiling the compiler does not make the bug go away. Compiling GCC with TCC does not fix bugs in GCC (otherwise people would be doing it more often).
Compiler have bugs, and some of these bugs cause them to silently emit the wrong assembly code for the source program passed to them. One of the authors of the original article that inspired bcrypt's blog post reported hundreds of bugs in Clang and GCC, of which about half are “wrong code” bugs: https://github.com/csmith-project/csmith/blob/master/BUGS_RE...
You are right that Debian and other distributions assume that compilers do not have “wrong code” bugs, though. The only problem is that this is not true.