swarm: tests and docs for the queue-credential revocation

Pins the three properties the revocation rests on and cannot check
against a store: that only `Destroyed` revokes (a revocation on
`Offline` or `Paused` would give an agent that stops and never
restarts), that a 404 is absence while a 403 stays a failure, and that
the delete addresses `secret/metadata/` -- the path that takes every
version, which is the string the grant has to match.

docs/swarm/credentials.md gains the revocation section and its table
cell stops describing the deletion as something an operator does by
hand.

swarm-secret-client/src/client.rs

@@ -633,8 +633,14 @@ mod tests {
     ///
     /// The distinction is the whole point of the verb: the data path's delete
     /// leaves earlier versions readable, so revoking a secret that was ever
-    /// rewritten there would leave the old value recoverable. It is also a
-    /// separately-ACL'd path, which is why the grant had to gain a stanza.
+    /// rewritten there would leave the old value recoverable.
+    ///
+    /// Asserted on [`vaultrs`]'s own request type rather than on a call, since
+    /// there is no store to call: it pins the endpoint
+    /// `kv2::delete_metadata` targets, which is the string
+    /// `swarm-bao.nix`'s grant has to match. A dependency bump that moved it
+    /// would otherwise surface as a 403 at the first revocation, far from
+    /// here.
     #[test]
     fn a_revocation_targets_every_version_and_not_just_the_newest() {
         use rustify::endpoint::Endpoint as _;