fix(ssl): include ACME error message in operator-facing warnings

[mrrobot47]

Problem

SSL issuance/renewal failures logged the real exception only via EE::debug() and showed operators a generic EE::warning(). Renewal runs unattended (cron) without --debug, so the actual ACME error (rate-limit reason, badNonce, accountDoesNotExist, a finalize/storage failure, etc.) — the single most useful diagnostic — was lost.

Separately, both executeRenewal() catch blocks emitted a hard-coded "Challenge Authorization failed. Check logs and check if your domain is pointed correctly to this server.". These catches fire for any exception/throwable (finalize failure, cert-store write error, etc.), so that line frequently misdirected operators toward a DNS/challenge problem that wasn't the cause.

Fix

• Append the concise $e->getMessage() to the operator-facing EE::warning in check() and both executeRenewal() catches (full detail still logged at debug).
• Drop the misleading generic "Challenge Authorization failed…" line from the executeRenewal() catches; the now-specific message and the existing "re-run ssl-verify" hint remain.

Notes

The exception text surfaces at warning level. ACME error strings contain no account-key material or JWS tokens (the ACME server never echoes those); the only incremental disclosure is absolute server paths on filesystem errors, acceptable for operator-run CLI tooling (the pre-existing EE::debug(print_r($e)) already dumped far more).

Testing

Manual: trigger a renewal failure (unreachable domain / rate-limit) without --debug and confirm the warning now carries the ACME reason.

[Copilot]

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