docs: tell the whole daemon story, and stop denying it exists

An audit of the README and the site against the implementation found 38
places the docs were missing, stale, or wrong about daemon mode. Two were
outright false: the community page still answered "want a queue that
outlives the command?" with "slskd has that", and the home page promised
"no daemon, no API to stand up" fifty lines before the section that
describes both.

The download-box walkthrough now tells the truth about its sharp edges: a
pushed folder or share list is live-only on a remote daemon, whose own
config.toml wins at restart; `shares add` validates the path on the
machine you type it on; and a `get` that reaches its `--timeout` cancels
the daemon-side transfer. Its shell example also runs as written now — the
old block put a second command after a foreground daemon that never
returns.

The reference material catches up with the feature: `daemon` and its
subcommands join the command list, the config table gains the
daemon/daemon_token/--no-daemon rows, nine settings become eleven,
`daemon status` and `daemon token` get documented record shapes, exit 3
covers daemons, `queued` joins the serve statuses, the credential-free
count goes 13 to 19, and the action-command count 4 to 6.

And the surprises are written down rather than discovered: the daemon does
not sweep the wishlist on its own; Windows has no socket and so no
auto-attach; the attached TUI's settings form edits the daemon's folders
and rewrites this machine's config.toml; `serve` monitors a daemon's
uploads instead of starting a second server; `whoami` reports the
daemon's world, with --no-daemon as the way out. The OpenRPC section names
the six event methods and the session-wide download.set_dir rule.

Site typechecks, lints, and builds through prerender; every claim was
verified against the cited code before it was written.

website/src/pages/home.tsx

@@ -232,8 +232,10 @@ const About = () => (
         <Callout title="agents and automation">
           <p>
             Every command runs as a one-off from the shell. Point cron, a script, or an
-            agent at them and read JSON records back off stdout. No daemon, no API to stand
-            up. <Code>skills install</Code> teaches the agent the surface for you.{' '}
+            agent at them and read JSON records back off stdout. Nothing to stand up first;{' '}
+            <Code>soulseek-rs daemon</Code> is one command when a batch of them should share
+            a single login, and the agent skill starts one for you.{' '}
+            <Code>skills install</Code> teaches the agent the surface.{' '}
             <Link to="/docs" className="text-link hover:text-link-hover">
               See the commands
             </Link>