swarm-bao: make the store's name resolve where the store runs

Nothing resolved `bao.<swarm.domain>`. It is absent from
`swarm.serviceDomains` and, unlike every other swarm service, contributed
no `gateway.localNames` entry — so the name a reader dials answered only
if an operator had published an external record, which nothing asks them
to do.

Cross-hive traffic goes via the domain either way; only what it resolves
to varies, and for a multi-host swarm that is the operator's upstream DNS.
This covers the deployment with no upstream record to configure.

DNS only, and that asymmetry is deliberate: bao stays out of
`serviceDomains` and gets no vhost. Its leaf comes from its own CA, so a
services-CA entry would mint one nothing uses, and nginx terminating TLS
would strip the client certificate the store authenticates every hive
with. `swarm-nats.nix` documents the same exclusion for itself.

module-eval gains the presence and absence arms: claiming a name this
host does not serve would point every local reader at the wrong machine.

Refs #3862

nix/host-modules/swarm-bao.nix

@@ -418,6 +418,18 @@ in
           '';
         }
       ];
+
+      # The name every reader dials, made resolvable where the store runs.
+      # Cross-hive traffic always goes via the domain; only what it resolves
+      # to varies, and a multi-host swarm is the operator's upstream DNS. This
+      # covers the case that has no upstream record to configure.
+      #
+      # ⚠️ DNS only. Bao is deliberately absent from `swarm.serviceDomains`
+      # and gets no vhost: nginx terminating TLS would strip the client
+      # certificate, which is how the store authenticates every hive — see
+      # this file's header. `localNames` is the one half of the sibling
+      # pattern that applies.
+      services.hyperhive.gateway.localNames = [ cfg.domain ];
     })
 
     (lib.mkIf (hyperhiveCfg.enable && deployCfg.bao.enable && haveServerTls) {