docs(serve): say that serve runs the Telegram and Discord channels

[plombeer31]

Someone asked this in Discord and nobody answered it (adithr, 2026-09-08):

Is there any way to allow discord to stay active without a atag instance open?

There is: atomic-agent serve. It is just undiscoverable — nothing user-facing says so. This PR is documentation only; no behaviour changes.

What the code actually does

• serveCommand (src/cli/serve-command.ts) calls createAgentRuntime with workingDir / approvalLevel / traceDefault / handlers only. There is no option that suppresses channels, and none exists in AgentRuntimeOptions.
• createAgentRuntime (src/runtime/bootstrap.ts) constructs TelegramChannel and DiscordChannel unconditionally and fires start() when config.telegram.enabled / config.discord.enabled. The SwarmRegistry is built in the same block and startEnabled() starts every unit whose config is enabled and whose token env var resolves (src/channels/swarm/swarm-registry.ts). So a plain atomic-agent serve keeps Telegram, Discord and the swarm bots live with no TUI attached.
• The serve --help text advertised the command purely as "start the OpenAI-compatible HTTP API" and never mentioned channels — that is the discoverability gap this fixes.

The lock

TelegramLockfile / DiscordLockfile (src/channels/telegram/telegram-lockfile.ts, src/channels/discord/discord-lockfile.ts) write the PID with flag: "wx". On EEXIST they read the holder's PID and, if it is a different live process (process.kill(pid, 0)), throw formatChannelLockHeld(pid); a stale lock whose PID is gone is reclaimed transparently.

So: the first process to start a channel wins. In the loser, DiscordChannel.start() catches the throw and calls fail(...), and TelegramChannel.start() catches it and transitions to down — in both cases the channel settles at down with reason channel-locked: already running in another atomic-agent (pid N) and never retries; it only tries again if something calls start() again (config toggle, restart). The Integrations pane renders that reason as configured, not error (src/integrations/telegram-integration.ts, src/integrations/discord-integration.ts), because the bot is up — just served from the other process.

What changed

• HELP in src/cli/serve-command.ts: a Remote channels: block in the same terse aligned style, stating that enabled Telegram/Discord/swarm bots run in this process, that nothing restarts the process for you, and what the single-instance lock means alongside a TUI.
• README.md: one paragraph in the OpenAI-compatible HTTP block and one in the Telegram remote control block, cross-referencing the same fact.

What I checked and did NOT change

• Grepped README.md and every top-level *.md for serve / headless / daemon / telegram / discord. The only existing statement of this fact is in AGENTS.md (contributor doc, Telegram section) — nothing user-facing.
• No new flags, no auto-restart promise (there is none), no TUI changes, no nohup/systemd/launchd recipe (the README does not talk about long-running processes that way).
• Discord has no README section of its own; rather than invent one here, the cross-reference lives where remote control is already documented.

npm run lint passes; npx vitest run src/cli is 17 files / 182 tests green (no test asserts on the serve help text).