It depends. There is not enough information in your question to give specific answers, and probably without knowing the server side, it will be hard to evaluate.
Isn't this a breach?
I would not call it a breach just yet, because simply knowing the fact that the client hashes the password does not reveal any sensitive information about this or other accounts.
Can't an attacker sniff the passwords easily, or do a send-the-hash attack?
If an attacker can sniff the communication between the client and the server, it makes no difference, wether the original password is sent or a hash version of it. In both cases, the attacker has the credentials needed. The only thing that could stop them now would be two-factor authentication.
The best thing to do agains sniffing is enforcing HTTPS for the communication.
Is it really "salt" if it's the same for everyone?
No, a salt is some random data that is added to a one way hash function to safeguarde passwords in storage. A salt must be random and be unique for each password and should be long enough to protect agains creating rainbow tables with all possible salt combinations.
It's also not a pepper, because a pepper must be secret.
Why would you hash a password on the client side in the first place?
Hashing a password on the client side before submitting it to the server simply turns the resulting hash into the new password. While it provides no additional security during the authentication process, it protects the user's password in general (especially if they use it elsewhere as well): the clear text password is never transmitted nor processed by the server. If the server (in contrast to the database) is ever compromised, it will be more difficult to extract the original password.
PS: Hashing something with a hash function like md5 or sha is different from encrypting something. Encrypted data can be decrypted, hashed data however can not be restored as a hash is a one-way function.