swarm: the contract for an agent's bash task status and output

A status key per task in the bash-task-status bucket and the task's output rows
in a per-agent stream, kept apart as for subagents. The controller creates the
bucket and the streams, and the agent credential may publish its own keys and
subjects. Nothing publishes yet; the bash MCP half follows.

docs/4-implementation/swarm/controller.md

@@ -190,6 +190,19 @@ publish `$KV.subagent-status.<agent>.*` and nothing else of the bucket. Keeping
 this apart from the rows means a list of subagents reads one small value each
 and never a terminal stream.
 
+Its bash MCP will publish the agent's background tasks the same way, with the
+status kept apart from the output. A task's status is one key, `<agent>.<task>`, in the
+`bash-task-status` bucket: its `state` (`pending`, `running`, `done`, `timed_out`,
+`interrupted` or `killed`), the command cut to 200 characters, when it began and when it
+entered its state, the exit status, and `ts`, the time of the publish. A live task republishes
+every 60 seconds, and a reader treats a live value older than three of those as stale. The output
+goes to `$SWARM.term.<agent>.bash.<task>`, with a `Swarm-Stream` header of `stdout` or
+`stderr`, into the stream `term-bash-<agent>` that swarm-controller creates for every declared
+agent, for 24 hours or 64 MiB like the subagent rows. The agent's credential may publish
+`$KV.bash-task-status.<agent>.*` and `$SWARM.term.<agent>.bash.>` and nothing else of
+JetStream. Only the names, the grants and the two stores exist so far; the bash MCP doesn't
+publish yet.
+
 The queue would refuse a row too large for its `max_payload` outright and
 take the connection down with it, so the harness drops such a row's body before
 sending and leaves a marker in its place; the summary, level and icon still