Let the panel check accept the same certificate the deploy already does

The check required a certificate curl would validate. The FTP host presents one
it will not, so the check failed the handshake and -- before the previous
commit taught it to say so -- reported the folder as missing. It has blocked
every admin deploy since, including ones that would have succeeded.

A guard stricter than the thing it guards blocks work without protecting
anything. The deploy step completes FTPS against this host regardless, so the
upload already carries these credentials over a connection whose certificate
nobody verified. Matching that is not a new exposure; it is the check stopping
pretending to a standard the pipeline does not meet.

The fix that would let this be strict is a valid certificate on the FTP host,
which is Hostinger's to provide, and the comment says so where someone would
look.

Verified the three outcomes still hold with the flag in place: the panel folder
passes, a folder without config.php fails and lists what is there, an
unreachable host reports curl's error. The certificate case itself could not be
reproduced here -- this sandbox blocks generating a self-signed certificate to
test against -- so that path rests on curl's documented behaviour and the next
real run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0128YzbhrfGdegUSc9RrARRf

Author: claude

.github/workflows/deploy-admin.yml

@@ -161,8 +161,21 @@ jobs:
             # handshake and a blocked data connection all look exactly like an
             # empty directory -- and the check then reports the folder is wrong
             # when the truth is that it never got to look.
+            # --insecure encrypts the connection but does not verify the
+            # server's certificate. That is a real weakening and it is worth
+            # being explicit about why it is here: this host presents a
+            # certificate curl will not validate, and the deploy step below
+            # completes FTPS against it regardless -- so the upload, carrying
+            # the same credentials, already crosses an unverified channel.
+            # A check that is stricter than the deploy it guards blocks work
+            # without protecting anything; it did exactly that on its first
+            # run, reporting a folder as missing when it had simply been
+            # refused the handshake.
+            #
+            # The fix that would let this be strict is a valid certificate on
+            # the FTP host, which is Hostinger's to provide.
             set +e
-            listing="$(curl --silent --show-error --ssl-reqd --list-only \
+            listing="$(curl --silent --show-error --ssl-reqd --insecure --list-only \
                             --connect-timeout 20 --max-time 60 \
                             --config "$cfg" 2>"$cfg.err")"
             rc=$?