fix(ssl): detect and rebuild stale ACME orders on verify/retry

[mrrobot47]

Problem

A one-time DNS hiccup or timeout could permanently break SSL for a site. On issuance failure the ACME order/challenge files are left on disk; the user fixes DNS and re-runs ee site ssl-verify → check() blindly reloads the on-disk order and reuses it. Within ~7 days while the order is still pending this works (and is preserved). But once Let's Encrypt expires the order, or marks an authorization invalid after a failed validation, the reloaded order is dead and every retry fails (for an expired or purged authorization, with an uncaught 404 MalformedServerException) — because the retry path never requests a fresh order (only init_le calls authorize()).

Fix

check() now detects a stale stored order and rebuilds it before validating. isCertificateOrderStale() reloads, for each domain, the challenge the active solver uses (the same challenge check() validates; once one challenge is attempted Let's Encrypt drops the others). The order is stale when that challenge is invalid, when Let's Encrypt answers 404 for it (an expired authorization returns 404 "Expired authorization", a purged one "No such challenge"), or when the order lacks a requested domain. pending, processing and valid are live. On staleness it revokes the stored challenges (best effort) and calls authorize() for a fresh order; the stale order is kept until authorize() overwrites it, so a failed rebuild (rate limit, network) is retried on the next run instead of dead-ending.

Safeguards:

• A transient Let's Encrypt error (5xx/429/network) during the staleness check is inconclusive: the order is kept and no newOrder is spent. (The run itself still stops with the underlying error from the main validation loop, as before; that is a separate follow-up.)
• The creation path (fresh order) and the normal "DNS not ready yet, retry later" path (pending order) do not trigger a rebuild — behavior there is unchanged.
• For manual DNS-01 (no Cloudflare API key) a rebuild issues a new TXT value, so the command warns the user to publish the new record and re-run, instead of failing validation confusingly. HTTP-01 and Cloudflare-automated DNS continue to validation as before.

Known limitation

A user-run ee site ssl-verify <site> builds its domain list without www, so it only finds the stored order when that order is for the bare domain (sites whose www check failed at create time) or for DNS/wildcard sites. For HTTP-01 sites whose cert includes www, the stored order isn't found and this self-heal doesn't run; fixing ssl-verify's domain set is a separate follow-up. ssl-renew is unaffected (it always requests a fresh order).

Testing

Manual: on a site with a stored order for its domain set, point the stored challenge URLs at a nonexistent authorization (LE answers 404, like an expired one) and run ee site ssl-verify → "Stored ACME order is stale/expired; requesting a fresh order.", fresh challenge URLs in certificate_order.json, validation succeeds, and no new certificate while the current one is valid. Negative tests: a valid or pending order is not rebuilt (order file unchanged); with the ACME host unreachable the order is kept ("treating as inconclusive").

Tested on Ubuntu 26.04 with EasyEngine 4.12.0 against production Let's Encrypt (one certificate, then the stale-order, valid-order and unreachable cases on its stored order).

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.