feat(swarm-controller): serve the agent roster

GET /api/agents, beside the POST that creates one. The identity store is
the roster rather than a source to assemble one from, so this is a read
with nothing to merge or reconcile.

It says nothing about health, deliberately. A roster is the set other views
are complete against — it is what makes "this agent has never reported"
expressible, and that only survives while the declared set and the reported
set stay apart.

The two verbs treat a missing bridge differently and the asymmetry is the
design: POST queues a job that fails loud when claimed, GET has nowhere to
defer to and returns 503. Answering [] there would render a store nobody
could read as a swarm with no agents.

swarm-authelia-bridge/src/main.rs

@@ -6,7 +6,7 @@
 //! `swarm-authelia.nix`'s `unitName` already derives) — the same user
 //! authelia's own instance runs as, and therefore the file's actual
 //! owner. That is the whole answer to "how does an unprivileged
-//! `swarm-controller` write a file it doesn't own": it doesn't — this
+//! `swarm-controller` touch a file it doesn't own": it doesn't — this
 //! process does, sidestepping the uid boundary instead of bridging it
 //! with root/`CAP_CHOWN`/a shared group (all examined and rejected — see
 //! `swarmctl/README.md`'s own identical analysis of this same file).
@@ -27,11 +27,6 @@
 //! exists as an authelia subject, and list the ones that do. Not a
 //! wholesale-replace-the-file API — this process owns rendering
 //! `users.yml` internally; see `store` module.
-//!
-//! The read is here rather than in its caller for the same reason the
-//! write is: the store is owned by a uid `swarm-controller` does not have,
-//! and a caller that opened the file itself would be a second parser of a
-//! format this process owns.
 
 mod introspect;
 mod store;