The "share which expires after one use" part requires the password either be visible to the server or encoded in the URL (also visible to to the server) unless you also want to share a password/key to access the password or, in which case the site doesn't make sense, or you want to require both folks are online at the same time to make a brokered WebRTC connection and share via that channel.
I think the intent is you have some crap messaging platform like email or SMS without and want to send a one time access link to the password. I'm not really sure how large the intersection of people who care enough about security to want that but not enough to want to avoid a 3rd party server and hoping first access of the link contents is by the intended target is though.
The server store encrypted password identified by item id. Browser side decrypt the encrypted password using key in the hash part. The hash part does not reach the server.
The full URL gets sent to the server on connection. You could break this out from the link, at which point you're back to sharing a password to share a password.
It has to, how would it deliver the password to the URL’s recipient otherwise?
I suppose to keep it fully stateless you could encode the password in the URL itself somehow, but then that would defeat the purpose of not having the secret hang around in perpetuity.