fix(api-server): require auth for /health/detailed and fail closed on weak keys

[hashbender]

Summary

The API server's /health/detailed endpoint now requires Bearer auth, and the server refuses to start on a weak/placeholder key on any bind — closing two external-surface fail-open paths.

Salvaged from NousResearch#44073 (@SahilRakhaiya05), split into a focused PR per maintainer request.

Changes

• gateway/platforms/api_server.py:
  • /health/detailed now runs _check_auth — it exposed gateway state, connected platforms, active-agent counts, PID, and exit reason with no auth. Plain /health stays open for container liveness probes.
  • Refuse to start on a placeholder or <16-char API_SERVER_KEY on all binds (previously only network-accessible binds). A guessable key on a terminal-capable endpoint is RCE-adjacent even on loopback. The required-key check was already unconditional; this extends the strength floor.
  • Startup guards (_api_key_passes_startup_guard, _port_is_available) are hoisted above app + background-task creation so a rejected start leaves no partial state.
• Tests: /health/detailed → 401 without auth / 200 with; weak key → refuse start with no app and no background tasks.

Validation

	Before	After
/health/detailed no auth	200 (leaks state)	401
/health/detailed with auth	—	200
Weak key on loopback	starts	refuses, no partial state
Plain /health liveness	200	200 (unchanged)
test_api_server*	pass	194 pass

Note: existing loopback deployments with a <16-char API_SERVER_KEY will now be refused at startup — intentional for a terminal-capable endpoint. Fix is to set a strong key (openssl rand -hex 32).

Infographic

---

Mirror-of: NousResearch#56260
NousResearch#56260