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/run.rs

@@ -84,12 +84,18 @@ pub fn run(mut cli: Cli, out: &Out) -> CliResult {
         }
         Commands::Shares(SharesCommand::Add { ref directory }) => {
             return crate::commands::settings::shares_add(
-                out, &store, directory,
+                out,
+                &store,
+                directory,
+                &live_daemon(&cli),
             );
         }
         Commands::Shares(SharesCommand::Remove { ref directory }) => {
             return crate::commands::settings::shares_remove(
-                out, &store, directory,
+                out,
+                &store,
+                directory,
+                &live_daemon(&cli),
             );
         }
         Commands::Wish(WishCommand::Add { ref query }) => {
@@ -243,6 +249,14 @@ fn context(
     })
 }
 
+/// The daemon a config change should also reach, if one is running.
+fn live_daemon(cli: &Cli) -> crate::commands::settings::LiveDaemon {
+    crate::commands::settings::LiveDaemon {
+        endpoint: daemon_endpoint(cli),
+        token: cli.daemon_token.clone(),
+    }
+}
+
 /// Ask a daemon what it is, so this run describes the session it will actually
 /// use. A daemon that cannot be reached is left to `Session::open` to report,
 /// which produces a better message than anything this early probe could.