Self-signed HTTPS in goosed breaks headless/server deployments (K8s health probes, reverse proxies)

[wpfleger96]

Summary

#7126 unconditionally replaced the plain HTTP listener (tokio::net::TcpListener::bind) with axum_server::bind_rustls using a self-signed certificate. This breaks all headless/server deployments where goosed runs behind a reverse proxy, sidecar, or Kubernetes health probes that expect plain HTTP.

Impact

This change landed on main after v1.26.1 was tagged, so no released version is affected yet. However, the next tagged release will break every non-desktop deployment unless TLS is made opt-in.

Affected scenarios:

• Kubernetes health probes — httpGet probes send plain HTTP to the goosed port and receive a TLS handshake back, causing malformed HTTP response "\x15\x03\x03\x00\x02\x022". Pods crash-loop as liveness probes fail.
• Sidecar proxies (Envoy, etc.) — sidecars communicating with goosed over localhost expect plain HTTP
• Python/HTTP clients — goose-python-client and any HTTP client hitting http://localhost:7879 gets a TLS error
• Any deployment where goosed is not spawned by the Electron desktop app

Reproduction

1. Build goosed from main (any commit after feat: self-signed HTTPS for goosed server #7126)
2. Run goosed agent with GOOSE_SERVER__SECRET_KEY set
3. Observe log: listening on https://0.0.0.0:7879
4. curl http://localhost:7879/status fails with a TLS error

Context

We discovered this while deploying a canary build in our Slack bot infrastructure. Our branch was based on main rather than v1.26.1, and every pod crash-looped because K8s liveness probes couldn't reach the /status endpoint over plain HTTP.

The self-signed TLS feature makes sense for the desktop app (Electron pins the cert fingerprint via the GOOSED_CERT_FINGERPRINT stdout output). But it should not be the only mode — server/headless deployments need plain HTTP.