Fix CA ordering so fresh `server install` clusters boot with etcd mTLS

SetupEtcdTLS (cli/commands/server.go:364, reached when distributed runners is enabled) requires <dataPath>/server/ca.crt to already exist, but the server's own create-if-missing LoadCA doesn't run until server.go:754, about 390 lines later inside Coordinator.Start. So the binary isn't self-sufficient for its own etcd TLS setup: it depends on an out-of-band auth generate, or a prior boot, having created the CA first.

That's fine for existing clusters (a prior boot already wrote the CA) and for make dev / make dev-distributed (they run auth generate before starting the server). It breaks fresh production installs: server install starts the systemd service before generating the CA, so with distributed runners on by default the first boot fails "CA certificate not found," crash-loops on Restart=always until the install's later auth generate lands, then self-heals, with the install's readiness check reporting failure in the meantime. A bare miren server on an empty data dir with no prior bootstrap fails permanently (chicken-and-egg: 364 always errors, so LoadCA at 754 is never reached).

Fix: ensure a CA exists before the etcd-TLS block, e.g. call LoadCA (create-if-missing) early in Server() before line 364, or reorder the server install flow to generate the CA before starting the service. Add a cold-boot test for a fresh server install with the flag on.