fix(a7-3/s1): require TLS or local transport for daemon auth

Daemon modules that declare 'auth users' no longer accept credentials over a
remote plaintext connection: server_module_gate refuses at the config gate,
before any SCRAM challenge is sent, unless the connection is verified TLS with
a client certificate matching --client-cn, or a local/SSH transport (loopback
TCP peer or the --stdio pipe). --allow-unauthenticated does not relax this.

The TLS client-CN comparison now uses credentials_secure_equal (S2). Clients
sending --password-file to a non-loopback daemon must use --tls; validate_config
rejects the plaintext case before any network I/O.

Adds utils_sockaddr_is_loopback / utils_fd_peer_is_local / utils_host_is_loopback
helpers with unit tests, a client validation unit test, and integration tests
for the client-side plaintext rejection and the wrong-CN gate refusal.

README.md

@@ -528,6 +528,16 @@ restart-gated enumeration channel remains (persisting a dummy key is out of
 scope); and the store iteration count is observable pre-auth by design, since
 the miss path must match a hit.
 
+An `auth users` module only accepts credentials over an encrypted, verified TLS
+connection whose client certificate matches the server's `--client-cn`, or over
+a local/SSH transport (a loopback TCP peer or the `--stdio` pipe). A remote
+plaintext peer is refused before any challenge is sent, and
+`--allow-unauthenticated` does **not** relax this: that flag only relaxes the
+standalone plaintext gate. Clients sending daemon credentials with
+`--password-file` to a non-loopback daemon must therefore use `--tls`; the
+client rejects a non-local plaintext credential destination before any network
+I/O.
+
 TLS provides encrypted TCP transport. Supplying `--ca` enables certificate
 verification; without it, traffic is encrypted but peer identity is not
 verified. Use certificate verification for deployments where authentication