Both using a random salt and several hash computations or another delaying strategy (bcrypt, scrypt, whichever) make sense not only for many users, but certainly also for one user.
Salt prevents an attacker from trivially entering your hash into Google to get an instant password without even using a tool. A good random salt makes it less likely that you've chosen one that someone else has built a rainbow table for the value anyway (such as for some obvious salts that you might see, like user IDs).
Having a different, random salt for every user prevents an attacker from reusing hashes in a rainbow table (or using a rainbow table for a specific salt that already exists readily). It forces to brute-force each individual user. You can't prevent someone from continuing a brute-force attack, and it will eventually be successful (since even "strong" passwords are relatively weak). But the longer it takes to brute-force one user, the safer the remaining ones are (if it takes 2 seconds to brute-force one user, you can do 1000 users in a few hours -- if it takes a week per user, things look much better). That is the whole point of using something like bcrypt.
Now if there is only one user, brute-forcing the first user means a 100% compromisation.
Therefore, using a strategy that delays brute-force is at least as important as with a many-user database (but conceptually more important).
Something like a GUID will do fine, it does not matter whether you store the "string" somewhere or whether you reuse it when the same user changes password. A salt needs to be accessible in some form so you can validate the password. Sure, it would of course be nice if you could keep it secret, but that is neither possible nor necessary for its purpose. Also, if someone can steal the salt, they will also have the hashed password, since that is usually stored in the same place. Insofar, there is no "additional risk" that someone might maybe prepare a rainbow table ahead of time for that known salt (before stealing the actual password). With that said, if you feel uneasy, it does not really cost anything to also change the salt every time the user changes password.
The purpose of the salt is not encryption of some kind but to thwart rainbow tables, which make inverting the hash function a trivial operation.
In principle, hardcoding a "randomly chosen" salt directly as you propose would be just as good for your one-user scenario. However, this is a bad approach since there is the possibility that you will eventually reuse the code for something else (a different project of yours) or that you will eventually have more than one user.
You may not see this coming right now, but it is generally a possibility.
Now the thing about things that may happen is that eventually they will happen. So if you directly hardcode a single salt since there's only one user anyway, you will eventually have a security hole, maybe in 10 years from now when you don't even think about it any more.
As soon as you use the same salt for several users or for a single user in several projects, it is pretty useless. You should simply not make it possible for that to happen.
The same applies, of course, to the approach of having a "permanent" salt which you use everywhere, say, for the remainder of your life. This is an open invitation to building a rainbow table, since doing so will save computional work. Attacking one of your passwords will be more or less the same workload as attacking all passwords in your lifetime.
