[Disclosure: I work for 1Password]
These are really good questions. I am mostly adding to Ben's excellent answer, but I feel that I have enough additional to say to make this worth a separate answer.
You also mentioned that you hadn't seen this explained anywhere. Much of what I say is discussed in the first few chapters of the 1Password security design document (PDF).
You raised, directly or indirectly, a number of separate questions
Key derivation versus comparing hashes
Implicit in your question is a very understandable confusion between "hash and compare" authentication with the way that key derivation is used in many password managers. For traditional authentication systems, a hash of a password is stored, and a system will hash the user provided password and see if those match. If they match the system says "ok, you are who you say you are."
But that isn't the only way authentication can work (I will get to that later), and it certainly isn't the way that decryption works. For decryption you take the password (and other stuff) and derive a key that is used to decrypt (keys that can decrypt) your data.
Hashing is an part of key derivation, but the goal is to derive a secret that is not stored anywhere. It is not to derive a hash that gets compared to a stored hash.
With that out of the way, we can go on to your other questions.
How do different clients know how to derive the keys?
As you correctly noted, you need to be able to derive the same authentication and encryption keys on all of your devices for you to be able to use your data on all of them. This can be very safely managed. You stated your question in terms of hashing, but the more correct notion is key derivation.
When you first create your account, your client will pick some key derivation parameters and generate a non-secret salt. It will send that information to the server. There is nothing secret in that. (It will also send something else that I will get to later.)
I will talk about the choice of key derivation function (KDF) and its parameters as "KDF parameters" in what follows.
When you try to authenticate from a new device, you give the server your username. (In 1Password's case you need to give it some other account information as well, as you can have different accounts with the same username, but let's just pretend that you only need to give it your username.) The server will look up the KDF parameters that you'd sent it when the account was first created and it will send this to back to you on your new device
With the same salt and KDF parameters you can derive the same keys as long as you provide it with same master password (and other user secrets). The key derivation function is designed to be deterministic.
Not sending secrets during auth
In a traditional authentication process you send a secret, your password, to the server, the server hashes it and compares that hash with what it has stored. In the case of a password manager that involves sending a very high value secret to the server, which is not something we want. Even if the server were to forget the password sent to immediately after the hashing, there are numerous things to worry about with such a scheme. A bug or malicious code on the server would be able to capture and store those passwords. A very bad thing.
When we designed 1Password's authentication scheme we did not ever want to see your master password. There were roughly two approaches. One would be to have users have a different authentication password than an encryption password. There are ways of doing that under the hood to still live up to our name of one password. For reasons I won't get into, we rejected that approach as the various schemes still gave us too much information during authentication.
The other approach, which we took, was to use an authentication protocol that doesn't involve any secrets to be transmitted during authentication. We needed to use a PAKE (Password-based Authenticated Key Exchange). And the PAKE we chose was SRP (Secure Remote Password). Here, in somewhat abstract terms, is how that works.
When you first create your account you use the KDF and your master password (and other user secrets) to derive a key called the SRP-x. That SRP-x is your secret and should never be transmitted. You can always rederive it from your master password and the KDF parameters. From that x, you can compute something called the SRP verifier. It is possible to compute the verifier from the x, but the reverse is not possible. You transmit the SRP verifier to the server during enrollment, and that is the only time anything kind of secret gets transmitted.
During authentications, the server has the verifier stored and you can re-derive the SRP-x from your master password. Here is the cool part. There is a mathematical relationship between the x and the verifier that means that it is possible for each party to prove that they have x and v to each other without having to transmit any secrets. They mutually construct a math problem (which is unique for each authentication) that allows the server and the client to prove to the other that they hold their respective secrets (the verifier or the SRP-x) without revealing any secrets to each other or to an eavesdropper.
Separating encryption keys from authentication keys
The key derivation process allows the to derive a different secret used for encrypting/decrypting data and for authentication. So the SRP-x cannot be used to decrypt data. It can only be used for authentication as described above.