Recover capacity and placement after a worker loss

Repair invoice.yaml. Preserve apps/invoice (apps/v1 Deployment), three replicas, the invoice container and registry.example/invoice:6 image, with matching controller/template labels. Each replica must request at least 700m CPU and 384Mi memory; declare limits no smaller than requests and no larger than 1600m CPU/1536Mi memory. Requests reserve scheduling capacity; limits do not. Without admission defaults, a missing request inherits that resource's declared limit. All three replicas must fit jointly on eligible nodes in both stages. Normal residual CPU/memory: worker-a=1800m/1024Mi, worker-b=1400m/1024Mi, worker-c=750m/512Mi, overflow=3/2Gi, platform=8/8Gi, cordoned=8/8Gi. The loss stage removes worker-a and changes nothing else. All nodes are Ready and disk=ssd, zone=east. pool=app on worker-a/b/c and cordoned; pool=overflow on overflow; pool=platform on platform. overflow has dedicated=overflow:NoSchedule, platform has reserved=platform:NoSchedule, and cordoned is unschedulable; other nodes have no taints. Approved destinations are worker-a/b/c and overflow. Keep every other node ineligible, even if a witness packing could avoid it. nodeSelector ANDs with required nodeAffinity; terms OR together and expressions within each term AND together. Hard taints need matching tolerations, and tolerations cannot bypass cordon or readiness. Use compact requests on application nodes, or larger requests with approved overflow access. The supported subset is one Deployment with identity/selectors, one container's CPU/memory requests and limits, nodeSelector, required nodeAffinity and untimed tolerations. Inspect each stage's eligible nodes and actual packing, then repair without Reset.