Add experimental host_query API for local identity lookups

Programs running alongside nebula have no simple way to ask "who is this
vpn address?" when making authorization decisions, e.g. a nebula-aware
webapp that wants to identify an inbound connection by its source
address instead of presenting a login form. The existing surfaces are
the sshd admin interface (not scriptable from app code) and the
lighthouse-only DNS TXT lookup, which returns raw cert JSON over an
awkward transport.

This adds an opt-in `host_query` config section that serves a small
HTTP+JSON API on a unix socket or tcp address, requiring no client
library to consume:

  GET /v1/host?addr=<vpn addr>  identity of the host owning the address
                                (an established peer, or this node).
                                addr may include a port so a server can
                                pass a connection's RemoteAddr through
                                unparsed.
  GET /v1/self                  this node's own identity.

Responses carry the certificate-derived identity only: name, vpn
addresses, networks, unsafe networks, groups, fingerprint, issuer,
validity window, and cert version.

The self-vs-peer lookup logic is shared with the DNS TXT handler via a
new findCertificateForVpnAddr helper, which also swaps the panicking
GetDefaultCertificate call for the nil-returning accessor so a missing
certificate yields an empty answer instead of a crash.

The listener follows the statsServer lifecycle: the whole section is
reloadable via SIGHUP, including moving between socket paths and tcp
addresses. Unix sockets default to mode 0600, stale sockets left by an
unclean exit are removed at bind time, and a non-socket file at the
configured path is never replaced.

https://claude.ai/code/session_01Nibp24Pgk2JMue8VyWHq7o

examples/config.yml

@@ -223,6 +223,38 @@ punchy:
   # Overriding this to "" is the same as "/" and will allow overwriting any path on the host.
   #sandbox_dir: /var/tmp/nebula-debug
 
+# EXPERIMENTAL: this feature may change or disappear in the future.
+# host_query exposes a small local HTTP+JSON API that lets other programs on
+# this machine resolve a vpn address to its certificate identity (name, vpn
+# addresses, groups, fingerprint, validity), e.g. for making authorization
+# decisions about an inbound connection:
+#   GET /v1/host?addr=<vpn addr>  - identity of the host owning the address: a
+#     peer with an active tunnel, or this node itself. `addr` may include a
+#     port (`192.168.100.7:54321`), which is ignored, so a connection's remote
+#     address can be passed through as is. Returns 404 when the address is
+#     unknown or has no active tunnel.
+#   GET /v1/self                  - this node's own identity.
+# Identity answers can be trusted because nebula drops inbound packets whose
+# source vpn address is not contained in the sender's certificate, so the
+# source address of a connection arriving over the nebula interface is
+# guaranteed to map to the certificate reported here.
+# There is no authentication in this API; restrict access with unix socket
+# file permissions or by listening on a loopback address. Do NOT use a
+# non-loopback tcp address unless you intend to let everything that can reach
+# it query host identities.
+# This whole section is reloadable.
+#host_query:
+  # Toggles the feature
+  #enabled: false
+  # listen accepts a unix socket path or a tcp host:port:
+  #listen: unix:///var/run/nebula-host-query.sock
+  #listen: 127.0.0.1:8085
+  # File mode for the unix socket, as an octal string. Ignored for tcp.
+  # The socket is created by nebula's user; to grant a group of local services
+  # access, place the socket in a directory with appropriate permissions
+  # (e.g. a systemd RuntimeDirectory) and relax this to "0660".
+  #socket_mode: "0600"
+
 # EXPERIMENTAL: relay support for networks that can't establish direct connections.
 relay:
   # Relays are a list of Nebula IP's that peers can use to relay packets to me.