fix(ssl): warn when the letsencrypt account key is missing but cert state exists

[mrrobot47]

Problem

setAcmeClient() is binary: if the Let's Encrypt account key (acme-conf/account/key.private.pem) is present it loads it, otherwise it silently generates a new one. If that key is wiped while LE certs still exist (host migration, snapshot restore, mis-fired cleanup), the next run silently mints a fresh account key — orphaning the existing LE registration, so later renewals/issuance fail with 401s and no diagnostic.

Fix

Detect the lost-key anomaly and warn loudly (a lost LE account key cannot be recovered, so this is detect-and-warn, not auto-recovery). When the account key is missing AND prior LE state exists on disk — acme-conf/var/* (orders/challenges/DN) or acme-conf/certs/* (LE keypairs/certs), both written solely by AcmePhp — setAcmeClient() now emits clear warnings (the key appears lost; a new account will orphan the old one so existing certs won't renew until re-issued; restore acme-conf/account/ from backup to preserve it) before proceeding to generate.

The signal deliberately uses LE-specific acme-conf state, not services/nginx-proxy/certs/ (which also holds custom/self-signed certs), so it never false-positives on a non-LE host. On a genuine first run those dirs don't exist yet (AcmePhp creates them only after the account key), so issuance stays silent. The key-present load path and key generation are unchanged.

Testing

Manual: with existing LE sites, remove acme-conf/account/ and run any SSL op → the warnings fire instead of a silent re-mint; a fresh host (no acme-conf) and a custom/self-signed-only host stay silent.

[Copilot]

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