Recover health checks and a bounded rolling update

Repair processor.yaml. Preserve apps/processor (apps/v1 Deployment), three replicas, processor container, registry.example/processor:9 image and matching controller/template labels. The listener is HTTP port 8080. On cold start, /startup and /live return 200 at container age 40s; /ready returns 200 at age 50s. Earlier responses fail. The independent warm dependency profile starts healthy: during elapsed [20,40)s /ready fails while /live stays healthy. The warm fatal profile starts healthy but every path fails from elapsed 60s. Do not restart cold initialization or the transient dependency outage; restart the fatal failure by 75s. Readiness must never precede age 50s, must appear by 55s, must withdraw by dependency time 25s and recover by 45s. Configure readiness and liveness probes. A startup gate or delayed liveness may protect initialization. Roll from three healthy old replicas to three available new replicas by 180s, keep at least two available, at most four nonterminating Pods, and never exceed progressDeadlineSeconds. minReadySeconds requires consecutive readiness; maxSurge percentages round up and maxUnavailable percentages round down. In Kubernetes 1.35, a nonzero percentage that rounds both budgets to zero gives one unavailable Pod; explicit zero/zero is invalid. This simulation polls instant responses at initial delay then each period; startup gates other probes and consecutive thresholds apply. Restarts and old termination are immediate. Each second the model retires old Pods down to the configured minimum, then fills surge slots. It excludes jitter, latency, grace periods, backoff and scheduling. Edit only supported Deployment identity/selectors, RollingUpdate/minReady/progress fields, the container/ports and HTTP startup/liveness/readiness probes. Inspect profile and rollout evidence; repair without Reset.