maxSurge=0 vs maxSurge=1 for fixed-capacity RollingUpdate with readiness probes

A small application is being migrated with a Kubernetes Deployment using RollingUpdate. The goal is to keep the Service available during the rollout while the cluster has a fixed capacity ceiling that cannot be exceeded.

With maxSurge=0 the controller must terminate an old pod before a new one can be scheduled, which respects the resource ceiling but temporarily reduces the number of Ready pods that can serve traffic. With maxSurge=1 an additional pod can be created, shortening rollout time and preserving serving capacity, at the cost of transient resource contention if no spare headroom exists.

The unresolved behavior concerns readiness probe failures during the rollout. A new pod that does not become Ready stays out of Service endpoints, and the interaction with maxSurge and maxUnavailable determines whether capacity drops while waiting for readiness. The Deployment controller does not automatically roll back on readiness failure.

Which maxSurge setting preserves availability under a fixed capacity constraint when new pods may experience readiness lag? Does the controller retain old pods when new pods never become Ready with maxSurge=0 versus maxSurge=1? Is there a documented guarantee about endpoint availability in the window between old pod termination and new pod readiness?