fix(ssl): copy and validate custom certs on site update

[mrrobot47]

Problem

ee site update --ssl=custom set the DB flag and enabled HTTPS but never copied the certificate files. update_ssl() calls www_ssl_wrapper(), which explicitly skips all cert work for custom, and the cert-copy helpers (validate_site_custom_ssl() / custom_site_ssl()) were only invoked from the create path. Result: HTTPS turned on with no certs in nginx-proxy/certs/, so the site served a wrong/default cert. This is also the path Cloner.php recommends after cloning a custom-SSL site, so that guidance led to a broken state too.

Fix

In update_ssl(), when the target type is custom, mirror the create path: validate --ssl-key/--ssl-crt via validate_site_custom_ssl() and copy them via custom_site_ssl() before www_ssl_wrapper(). Also documents the --ssl-key/--ssl-crt flags and adds an example. Re-running this command is now also the way to replace an expiring custom cert.

Missing/invalid --ssl-key/--ssl-crt fails fast (inside the existing try/catch, before $site->save()), so there is no partial DB-vs-cert state.

Known limitation

If the post-copy bring-up (www_ssl_wrapper) throws, the copied cert files are left in place (no rollback); re-running the command overwrites them. The create path's catch_clean unwind is not mirrored here — a follow-up could unify the two cert paths.

Testing

Manual: create a non-SSL site, generate a self-signed key/crt, run ee site update <site> --ssl=custom --ssl-key=... --ssl-crt=..., and assert nginx-proxy/certs/<site>.key|.crt exist and the served cert matches.

[Copilot]

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