feat(grpc): encrypt the control channel with server-side TLS

[antoncxx]

On first boot, the control server now generates its own private CA
(members/nullnet-server/grpc-tls/ca-cert.pem + ca-key.pem, created once
and never regenerated) and signs its gRPC TLS leaf cert with it. Copy
ca-cert.pem to every client/proxy host and set CONTROL_SERVICE_CA_CERT
there — it's required: clients pin the channel to that CA and do full
standard chain validation (including hostname matching), so only a leaf
actually signed by it is accepted. Because clients trust the stable CA root
rather than the leaf, rotating the leaf later needs no client-side changes.

The leaf's SAN (needed for hostname validation) is derived in order:
CONTROL_SERVICE_TLS_SAN (explicit override) → the server's own
CONTROL_SERVICE_ADDR (often already the right value) → localhost.

On every boot, a persisted leaf is only reused if it actually verifies
against the persisted CA — issuer/subject match, signature, and expiry are
all checked cryptographically, not just "do the files exist." This catches
a stale leaf left over from an earlier iteration of this feature (before it
signed with a CA at all), or any other corruption/mismatch, and
regenerates just the leaf while keeping the existing CA intact — so
already-distributed client pins keep working.

Known limitation: client authentication (mTLS) remains a follow-up —
the server doesn't yet verify who's connecting, only the reverse.

[GyulyVGC]

@antoncxx is there a way we can simplify the configurations (CONTROL_SERVICE_CA_CERT env, certificate file distribution)?

We're moving towards getting centralised on the server, and before next week deployment it'd be ideal to have the least friction possible.

[antoncxx]

@GyulyVGC

Client/proxy no longer hard-require the env var — if unset they fall back to ca-cert.pem in the working directory and only fail once they actually try to read it