fix(shares): let add and remove reach a running daemon

shares add wrote the config file and stopped there, so with a daemon running
the folder stayed invisible to the network until the daemon restarted — the
command reported success and nothing had happened. Locally that is the right
meaning, because there is no session yet; a daemon is already the next run.

Both commands now push the new list over shares.set. The e2e test was checked
against a disabled push to confirm it detects the bug.

soulseek-rs/src/SKILL.md

@@ -120,7 +120,8 @@ clients never need it.
 
 **`shares list`** — one object per configured folder: `directory`, `usable`.
 **`shares add <directory>`** and **`shares remove <directory>`** — change the
-config file; they print nothing.
+config file; they print nothing. With a daemon running they also update it in
+place, so the folder is on the network at once rather than after a restart.
 **`shares status`** and **`shares reindex`** — `folders`, `files`,
 `directories`, counted by logging in and scanning.