grpc: terminate TLS and mTLS in the server

From crates/flexiq-server/README.md:

TLS is not terminated here; a bearer token proves who is calling and does not encrypt the
connection, so that belongs to a sidecar proxy or a service mesh.

That is a defensible position for a mesh deployment and an unreasonable one for everyone else.
A bearer token over cleartext is a bearer token in a log, and the deployments least likely to
have a mesh — a VM, a single box, a small Kubernetes cluster with no Istio — are the ones the
gRPC door is most useful to.

Add in-process TLS:

• Server TLS — certificate and key by path, configured by env like everything else, on the
  gRPC listener and on the attach listener. Both carry credentials.
• mTLS — optional client certificate verification against a CA bundle, as defence in depth
  beside the bearer token, not instead of it. The token still says which principal; the
  certificate says the connection is authorised to exist at all.
• Reload without restart, or a documented refusal. Certificates rotate on a 90-day cadence
  and the token store already reloads per call, so a restart-to-rotate story will look like an
  oversight.

Keep the sidecar path working and documented — a mesh deployment should not have to configure
TLS twice. This is an option, not a new requirement.

Start with crates/flexiq-server/README.md and trace how environment configuration reaches the gRPC and attach listeners. Define the optional certificate, key, and CA-bundle settings, then investigate whether certificate reload can follow the token store's per-call reload behavior; otherwise document the restart requirement. Done means both listeners carry configured credentials, optional mTLS verification works, and the sidecar path remains documented and usable.