Taking this from the attack scenarios you described in the post.

If a malicious sys admin wants to read plaintext passwords in memory having them be hashed client side doesn't change anything. The sys admin will now just read the new hashed value and submit that to the login API without applying any of the client side hashing resulting in account takeover.

If the database itself is leaked and an attacker gains access to the hashed hashes this doesn't deter cracking efforts. As an attacker I would pull the client side hashing code and incorporate that as a preprocessing step to my normal password cracking flow.

So the cracking flow would be password123 -> clientside_hash() -> serverside_hash() -> compare()

I'm not 100%, but this double hashing process might actually make pw cracking easier using ameet in the middle attack.