fix: dispatch zeroconf addUser from the current user

[molchalih]

A device that loses its connect state registration cannot recover on its own. The app falls back to the local addUser path, handleAddUser answers OK without dispatching, and nothing happens. The device never registers again and the app sits on "Connecting..." forever until the daemon is restarted.

What makes it unrecoverable is the currentUser arm. When the request comes from the user already holding the session it returns OK without creating a session and without logging anything, so the one recovery signal the app does send is swallowed.

This drops that arm so a same user addUser rebuilds the session and registers the device again. The authenticatingUser arm stays, so retries sent while one is already in flight are still absorbed. librespot-java and librespot have no guard on the user already holding the session and rebuild on every addUser.

How I hit it: a daemon up 20 hours. A capture during a tap shows getInfo returning 200 with activeUser set, then addUser answered {"status":101,"statusString":"OK"} repeatedly, while the log stayed empty and "accepted zeroconf" never appeared once in the whole run. Both sockets stayed up and the dealer kept its ping pong going, so the process was healthy. A restart fixed it instantly.

There was a dealer reconnect earlier in the day but I believe it recovered, since a successful re registration is silent at info level and a failed put would have warned. My reading is that the registration was dropped later on the server side with nothing visible to the client, similar to librespot-org/librespot#247. Either way addUser is the signal the app uses to recover and it should not be swallowed. I had no API credential to confirm the device was gone from the cloud device list, so that part is inferred.