If an attacker is able to place binaries in your home directory, he is also able to modify your path to prefer this binaries.
Removing ~/bin from PATH does not change anything.

Also the user would not be able to anything that they were not already allowed to do previously. If the user has the root passport, they are root.

If sudo is properly configured, this scenario does not cross security boundaries

I do not known much about shells and file privileges system, especially DAC, but changing owner of ~/.profile, ~/.bash_profile, ~/.bashrc will do nothing, cause attacker could replace these files. Simply remove and write new.

I think, solution could be:
let sudo check each parent executable. If it is named (file name, not invocation way) sudo, then real sudo will refuse to work.
We can think about what happens, if attacker wr9te own bash to handle sudo invocarion in different way or define sudo alias.

I think you are mistaken. In that case the user can only what we could already do: invoke sudo as per it's configuration. If the user has the root password they ARE ROOT.

Maybe I am mistaken, but on OpenSUSE, user could invoke any command as root by providing root password.

Attacker could place custom sudo (bash script) inside ~/bin, ~/.local/bin and told sudo (by providing full path) to invoke another command than user would like, for example:
 ~/bin/sudo file:
 #!/bin/bash
 /usr/bin/sudo rm -rf --no-reserve-root /

User would like to do: sudo zypper dup and system will invoke rm -rf --no-preserve-root / as root, because user happily provide root password.

So sudo on OpenSUSE was not configured good.

If an attacker has access to a user's account, and the user users the root password, then the attacker is already root and your example does cross a privilege boundary. You are describing a fundamental problem with probably a mis-unserstanding what sudo is and is not supposed to do.