muster release v5.16.0

Fixed

• A connected MCPServer whose backend stops answering is detected and reconnected (#493, #999). The orchestrator now probes every connected or running MCPServer with an MCP ping every 30 s (MUSTER_ORCHESTRATOR_HEALTH_CHECK_INTERVAL, a Go duration); each probe gets the server’s spec.timeout (default 30 s), and a backend that negotiated protocol 2026-07-28, where ping no longer exists, is probed with tools/list. Three failed probes in a row close the client and move the server to failed with a reconnect due at once: its tools are withdrawn from every session, one MCPServerHealthCheckFailed event names the count and the error, the CR status shows Failed with lastError and nextRetryAfter, and the reconnect loop restarts it on its next tick (MCPServerRecoveryStarted). A reconnect that fails follows the usual MCPServerFailed backoff schedule whatever the endpoint answered – a 404 from a route being reprogrammed as much as a refused connection – until the backend serves again. A passing probe, a successful start or a stop reset the count, so a single slow ping costs nothing; a JSON-RPC error reply, a probe cancelled by shutdown, and a server that is being stopped or restarted are not counted. Servers served per session (forwardToken, tokenExchange, OAuth) have no shared client and are not probed. Before, a server that reached connected stayed connected / healthy with its tools listed whatever happened to the connection afterwards – a redeployed, hung or dead backend meant every call failed until an operator ran core_service_restart; the service’s CheckHealth() existed but nothing called it. core_service_status exposes the running count as metadata.consecutiveHealthCheckFailures. The aggregator no longer emits a second MCPServerHealthCheckFailed for the same transition. Scenarios: mcpserver-health-probe-restarts-dead-backend, mcpserver-health-probe-restart-failure-is-retried, mcpserver-health-probe-spares-session-auth-server, mcpserver-health-probe-spares-per-session-oauth-server.