fix: mark GameServer Unhealthy when the game container terminates and the Pod stays Running

[GrowlyX]

What type of PR is this?

/kind bug

What this PR does / Why we need it:

I have a cluster with a Fleet that provisiones GameServers with a game container and several other sidecar containers. We had an issue where our main game container OOMKilled, but the pod stayed and was not replaced by Agones.

In failedContainer, when SidecarContainers is enabled, then it falls back to the Kubernetes behavior which requires every container in the pod to fail before the pod is marked as Failed.

This PR makes it so failedContainer reports the pod as Failed when the primary game container has terminated.

Which issue(s) this PR fixes:

N/A

Did you use AI tools in preparing this PR?:

Used for codegen & verifying the fix works

Special notes for your reviewer:

N/A

[Reasonably]

We hit this exact case in production with Agones v1.57 and SidecarContainers enabled.

The container referenced by spec.container terminated with exit code 137. Another regular container remained running, so the Pod stayed Running and the GameServer remained Allocated.

With restartPolicy: Never, a failed liveness probe can terminate the game container, but Kubernetes will not restart it. Once the container has terminated, its /gshealthz probe also stops. In our case the SDK sidecar recovered afterward, but there was no longer a running game container or probe to drive the health lifecycle.

Since failedContainer() returned false and the Pod never reached Failed, Agones had no remaining path to move the GameServer to Unhealthy.

Using the designated game container as the lifecycle signal is the behavior we expected. A terminated game container cannot recover under restartPolicy: Never, even if the rest of the Pod is still running.