fix: revert StatusProcessing to polling (revert pf9.5 re-finalization)

ZeroSSL ACME API investigation confirmed that the 403 orderNotReady on
the first finalize call is a false rejection — ZeroSSL internally accepts
the finalization and transitions the order to 'processing'. POSTing to
the finalize URL again while the order is in 'processing' is rejected
with 403 (correct per RFC: you don't re-finalize a processing order).

The correct behavior is to poll the order URL until ZeroSSL transitions
to 'valid'. pf9.4's finalizeOrder 403 handler correctly detects the
processing state and re-queues for polling. The long processing time
(25-30 min observed on 2026-06-17) is a ZeroSSL service quality issue,
not a cert-manager issue — likely due to account-level rate limiting
from many test runs in a single day.

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

Author: estenrye

pkg/controller/acmeorders/sync.go

@@ -246,13 +246,22 @@ func (c *controller) Sync(ctx context.Context, o *cmacme.Order) (err error) {
 	// valid or invalid.
 	//
 	// ZeroSSL exhibits non-standard ACME behavior: it returns 403 orderNotReady on the first finalize
-	// call and transitions the order to 'processing', but the order never self-transitions to 'valid'.
-	// A second finalize POST is required to trigger actual certificate issuance. We attempt re-finalization
-	// here; if ZeroSSL is not ready, it will return 403 again and the order cycles back to this case.
+	// call (even when the order is in 'ready' state), but internally accepts the finalization and
+	// transitions the order to 'processing'. The finalizeOrder 403 handler (below) detects this and
+	// sets the local order state to Processing. Subsequent attempts to re-POST to the finalize URL are
+	// rejected with 403 since the order is already being processed. The correct behavior is to poll
+	// until ZeroSSL transitions the order to 'valid' and a certificate URL is available.
 	case acmeOrder.Status == acmeapi.StatusProcessing:
-		log.V(logf.InfoLevel).Info("Order is in processing state, re-attempting finalization to handle servers that require a second finalize call")
+		log.V(logf.InfoLevel).Info("Order is in processing state, waiting for ACME server to update the status of the order...")
 		c.setOrderState(&o.Status, string(cmacme.Processing))
-		return c.finalizeOrder(ctx, cl, o, genericIssuer)
+
+		// Re-queue the Order to be processed again after RequeuePeriod has passed.
+		c.scheduledWorkQueue.Add(types.NamespacedName{
+			Name:      o.Name,
+			Namespace: o.Namespace,
+		}, RequeuePeriod)
+
+		return nil
 
 	case !anyChallengesFailed(challenges) && allChallengesFinal(challenges):
 		log.V(logf.DebugLevel).Info("All challenges are in a final state, updating order state")