swarm-nats-auth: limit agent subscribe to its own inbox and input

An agent's queue credential could subscribe to every subject in the swarm
account, so any agent could read every other agent's terminal, turn state,
operator input and request replies. Agents are the least trusted clients
on the queue (mara's ruling on #4901), so their grants now carry a
subscribe allow-list:

- an agent's own credential (the harness and its subagent daemon):
  `_INBOX.agent.<agent>.>` and `$SWARM.input.<agent>`
- the hive's shared agent client: `_INBOX.client.<client-id>.>`

Hive and swarm-controller grants are unchanged (no `sub` claim, so still
every subject).

The clients connect with the matching inbox prefix, so the replies they
rely on still arrive: the icon write's JetStream ack and the schedule
DIRECT.GET. `connect_with_token` takes the agent name and sets the prefix
itself; the hive-shared fallback uses the new
`connect_with_inbox_prefix`.

The harness no longer subscribes to its input subject when it fell back
to the hive's shared client: that identity names no agent, so it cannot
be granted one agent's input without all of them. It logs that and
skips, the same as the schedule reader on that path.

Refs #4901

docs/swarm/ui.md

@@ -78,7 +78,9 @@ request, replacing any the browser sent. `POST /api/agents/<name>/input`
 takes that header as the sender and sends `{from, body}` as a NATS request on
 `$SWARM.input.<name>`. swarm-controller is the only queue client allowed to
 publish there. The agent's harness subscribes to its own subject and queues
-each message for its turn loop with its reminders. The harness doesn't reply,
+each message for its turn loop with its reminders. Only an agent connected with
+its own queue credential may subscribe there; an agent on its hive's shared
+client takes no input this way, and the request gets the 503 below. The harness doesn't reply,
 so swarm-controller answers 202 when the request times out after two seconds,
 and 503 when the queue reports no subscriber.