swarm-nats-auth: open sealed callout requests and seal the replies

When nats-server has an auth_callout xkey it seals each request to that
key and names its own public xkey in the Nats-Server-Xkey header. The
responder now loads the callout xkey seed from the secret store before
it connects, opens a sealed request with it, and seals its reply (grant
or deny) back to the header's key. A request with no header is answered
in plaintext, as before.

A new `ensure-xkey` verb creates the pair when the store holds no seed:
the seed at swarm/services/swarm-nats/callout/xkey-seed, the public half
at swarm/public/swarm-nats/callout-xkey. Each write is a create-only
(cas=0) write, and a run whose create fails reads the stored value back,
so two concurrent runs end up with one key. The responder itself only
reads the seed and refuses to start without it.

swarm-secret-client gains SecretStore::create, the cas=0 write.

swarm-nats-auth/README.md

@@ -33,6 +33,21 @@ reintroduces the bug. `nats-jwt` is a **dev-dependency**: it cannot express
 `aud` on either token, and its role here is as the encoder's _test oracle_,
 not part of the path that runs.
 
+## The sealed exchange
+
+The server seals each auth request to the callout xkey and names its own
+public xkey in the `Nats-Server-Xkey` header; the responder opens the request
+with the xkey's seed and seals its reply to that header's key. It answers a
+request with no header in plaintext, which is what a server with no xkey
+configured reads.
+
+The seed is in the swarm secret store, and the responder reads it before it
+connects to the queue: a responder without it doesn't start. The
+`ensure-xkey` verb creates the pair when the store holds none. It runs from
+its own unit before the server, because the server needs the public half to
+start and the responder needs the server. `docs/swarm/secrets.md` has the
+paths and the boot order.
+
 ## Rules the code follows
 
 - **A denial is a signed response carrying an error, never silence.** The