Short: There is not much security improvement for hashing again. But hash is better than plaintext (does not directly leak password).
The second hash is apparently intended to protect against retrieving passwords in case the database gets compromised? In this scenario, the protection is only as good as how hard it is to resolve input $_POST['hash'] to hash operation. This input is not sufficiently unpredictable, at least not when weak keys are used.
There are some suggestions you could try to make things stronger.
Password-based key derivation
Usual hashing is not recommended way to deal with passwords. This is because at least fraction of users always tend to have very weak passwords. Weak password is always weak, but there are better ways than usual hash to work with passwords. scrypt paper illustrates the efficiency of different PBKDF's (and some hashes) against brute-forcing passwords of varying entropy levels.
If you want to protect the password+username better, do not use use sha256, but password-based key derivation function (also known as slow hash or password hash - some of these actually use sha256 under the hood; search scrypt, bcrypt, PBKDF2 for details).
The combination of Password+Username is (often) vulnerable to brute force guessing as well as rainbow tables. (In case you expect that the SSL connection does not sufficiently protect the credentials.)
BTW, if you calculate the password hash on client side, it may be possible to remove need for server side ever to know the password. This way, the possibility of the website leaking the password is significantly diminished.
If the user uses the same or similar password on other sites, the result is not usable for these purposes.
Using same authentication info each time
I understood that the user authenticates with
js > hash = sha256(Password+Username);
always. Right? This has possibility for replaying the credentials later. (Note: In many cases SSL prevents record&replay, but fact that CAs have been occasionally broken, makes it not always foolproof.)
To remove this replay possibility, you could do as follows:
If the server knows their password's derived version (either PBKDF result or above hash [i.e. it is stored on server when they are first authenticated]), instead of ever sending the value again, it could be used challenge-response protocol.
Some more complex challenge-response protocols, such as SRP are based on "zero-knowledge", and provide nice provable security concepts. Even fairly simple challenge-response protocols can preclude need to send the password or password-derived value directly, but just has client sending something that'll convince the server, but not allowing a replay.
There is a related question on crypto.SE: Is using slow password hashing on the client side easier attackable than on the server side? where Paŭlo Ebermann suggested client-based PBKDF and the best answer by Thomas Pornin also suggests to apply PAKE (SRP).