Yes, you're correct. I wouldn't say it would be trivial to crack a password once you have the salt, but it would be much easier.

Salts effectively make a password longer, without more for the user has to remember. The purpose is to make it much harder to make rainbow tables that will be effective on a system that uses salts (Now you have to have a rainbow table that has a hash for every possible salt for just the word "password"!)

Salts are typically stored with the hash, so if you get one, you get the other. In the case you don't get the salt, well, you're left with a very long salt+password combination to break (good luck). With the salt, you can break shorter passwords in a reasonable amount of time (depending on how computationally expensive the hash is).

With a salted hash, the only real feasible way is to just brute force it. That's exactly what this NSA@Home thing does. It just may require a small amount of tweaking to make sure to prepend the salt to every password attempt, but basically it is a very capable hash cracker.

Maybe I'm misunderstanding how the hashes are being cracked, but I was under the impression that this is cycling through all possible inputs, hashing them, and comparing to the given user input. However, I believe the original value is restricted to being 8 characters long (assuming that's what this means: "capable of searching the full 8-character keyspace (from a 64-character set)"). By salting your hash, you make the input to the hash function much larger. Then it's quite a bit over 8 characters and no longer feasible to crack.

The salt value is public. You don't have to brute force it. This isn't a "rainbow table"; it's exhausting the secret input to the hash function itself. Your analysis is broken.

Salts are never public. You're assuming that the salt is obtained along with the hash, which may sometimes but not always be true. However, I did understate the usefulness of this method since I was assuming the attacker doesn't have the salt, which often may not be the case.