I think that different parts of your plan vary in usefulness from "that's a different way to do it but won't hurt anything" to "that's a severe security vulnerability". In detail:
Possibly out of the norm
I don't normally hash the password client-side. That being said, I think there are other applications out there that do hash client-side for performance reasons, so this isn't crazy. However, I think in this case you have made some choices as a result of your client-side hashing that are bad.
Different, but probably fine
Having an increasing work function is perfectly normal and even good. The idea is that as time changes you increase the work value across your system to make it harder to crack passwords. As you obviously understand, the more "iterations" you have to go through to build the hash, the harder it is to crack a password, since any crack attempts have to match your number of iterations. In terms of actually doing that, there are some important considerations here:
1) (actually, a nitpick). Repeated hashing doesn't actually change your entropy at all. High entropy = more secure, so if your algorithm is decreasing entropy (as you said in your answer), that would be a bad thing. Either way, your increasing work function doesn't actually increase or decrease entropy.
2) The trouble with your plan, because you do things client side, is that you can't adjust the work function over time to account for advances in computing power. With server-side it is very easy to update your work function over time. If you want to make cracking more expensive, you just re-calculate the hash of the password with a higher work function the next time the user logs in. Then, you can store both the password and the work function in the database. Because your server never sees the password, you can't update the hash without additional back-and-forth between the client and server.
Potentially large security hole
This is a gigantic problem, I think:
set cookie("h", h)
The issue is that you are sending the hash back to the client in a cookie. The other part of the issue is that the server accepts this same hash directly to login the user. Therefore, you are effectively storing the user's password in a cookie, which is about the least secure place ever. Someone who managed to steal that cookie would then be able to login as the user until the user changes their password.
Normally the only thing you store in the cookie is a session id, and on the server side you associate that session id with the logged in user. If the session id is stolen (or even suspected of having been compromised), you can simply invalidate the session id. The attacker then loses all access and the legitimate user just has to log back in.
Never, under any circumstance, store either the password or the hash of the password in a cookie. Both should be completely forgotten (client-side) after a successful login.