Lemon-miaow
7f7e459746
Previously a server whose pod was ready but RCON probe kept failing would stay in Starting phase forever. The CRD defines TimeoutSeconds and ReadinessTimeoutSeconds but the reconciler never checked them. - PodNotReady path: if the pod stays not-ready past timeoutSeconds (default 300s), transition to Failed - RCON unreachable path: if RCON stays unreachable past readinessTimeoutSeconds (default 300s), transition to Failed - Helper methods startupTimedOut/readinessTimedOut compare StartRequestedAt against the respective timeout, falling back to 300s defaults when unset - 2 new tests: ReadinessTimeoutConvertsToFailed, StartupTimeoutConvertsToFailed Fixes the scenario where a broken backend (bad jar, crash-looping process) would permanently occupy a Starting server slot.