fix: handle processing state in finalizeOrder 403 handler for ZeroSSL

ZeroSSL returns HTTP 403 orderNotReady on the first finalize call even
when all authorizations are valid, and immediately transitions the order
to 'processing' state server-side. The existing code only checked for
'valid' state after a 403, falling through to the generic 4xx error
handler which incorrectly marks the order as 'errored'.

Add an explicit 'processing' check in the 403 handler: when getACMEOrder
returns StatusProcessing, set the local order state to Processing and
re-queue via scheduledWorkQueue. The main sync loop (StatusProcessing
case added by upstream PR cert-manager#7583) then polls until the order becomes valid.

This fix, combined with the earlier StatusProcessing case in the main
sync loop and the 90s context timeout on the finalize HTTP call, provides
complete ZeroSSL ACME compatibility.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: estenrye

pkg/controller/acmeorders/sync.go

@@ -608,6 +608,19 @@ func (c *controller) finalizeOrder(ctx context.Context, cl acmecl.Interface, o *
 			return c.syncCertificateDataWithOrder(ctx, cl, *acmeOrder, o, issuer)
 		}
 
+		// Some ACME servers (e.g. ZeroSSL) return 403 orderNotReady on the first
+		// finalize call and immediately transition the order to 'processing' state.
+		// When this happens, re-queue so the main sync loop can poll until valid.
+		if acmeOrder.Status == acmeapi.StatusProcessing {
+			log.V(logf.InfoLevel).Info("Order transitioned to processing state after 403 orderNotReady, re-queuing to poll for completion")
+			c.setOrderState(&o.Status, string(cmacme.Processing))
+			c.scheduledWorkQueue.Add(types.NamespacedName{
+				Name:      o.Name,
+				Namespace: o.Namespace,
+			}, RequeuePeriod)
+			return nil
+		}
+
 	}
 
 	// Any other ACME 4xx error means that the Order can be considered failed.