Wouldn't that allow for a compromised database to leak the information a nefarious user needs to log into accounts? Compared to needing to find a collision if a database of hashes leaked?

I think client-side password hashing is generally in addition to server-side hashing. Not instead of it.

Can you elaborate on how this makes things more secure (assuming HTTPS)

Surely if the server accepts a client side hash of a password, then the hash has become the password

At that point you can do key derivation to get an ed25519 private key from the password and a server-supplied salt (specific to that user), after which the client signs a challenge the server supplied with that private key. When the password was set/changed, the corresponding public key was stored on the server.

Off the top of my mind. Maybe it could be something like that:

1. Api gives user a fixed salt.

2. User types password into input.

3. Client hashes and sends hash to server.

4. Server has another salt and uses the client sent hash to hash it again.

5. This final hash is compared what is in the database.

This way server never has knowledge of the original PW and it's never sent over the network. This reduces for instance the chance of password getting logged in the service etc.

But in that case the hash sent to the server in stage 3 is always the same and behaves like a password - capture it and you can use it again elsewhere.