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.

docs/daemon-protocol.md

@@ -143,6 +143,11 @@ configuration and a client cannot name one — that would be an arbitrary write
 on the daemon's host. `daemon.status` reports the directory in use. There is
 no method to fetch the bytes over the control socket.
 
+**Configuration is per machine, shares are per session.** A client's config
+file is its own; changing it does not reach a daemon. The exception is
+`shares.set`, which the CLI's `shares add`/`remove` call so a folder is served
+without waiting for a restart.
+
 **Several clients, no locking.** Last write wins. Two clients cancelling the
 same transfer is two hands on one keyboard, not an error.