fix(sys-svc-webserver-core): explicit HTTPS default_server rejects unknown SNI

Adds a `listen 443 ssl default_server` block with `ssl_reject_handshake
on;` to default_server.conf.j2. Without this, when an SNI request hits
a hostname whose vhost has been purged (e.g. dashboard.infinito.example
after the fresh-purge sweep between matrix-deploy variants), openresty
silently falls onto whichever ssl-listening server happens to load
first and responds — bluesky-pds caught dashboard.infinito.example in
CI job 76714878217 and served its text/plain landing.

`ssl_reject_handshake on;` closes the TLS connection before any
certificate selection happens, so curl receives http_code "000" — the
exact contract the env-test `scripts/tests/environment/08_deploy_
performance.sh` already asserts after a matomo-only fresh-purged
deploy. Currently four devenv jobs (debian / centos / fedora /
manjaro) in workflow run 26089179898 fail with
`[FAIL] https://dashboard.infinito.example returned HTTP 301,
expected 000` because some downstream vhost answered instead.

Requires nginx >= 1.19.4 (openresty bundles 1.27 in this stack, so
the directive is available).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

roles/sys-svc-webserver-core/templates/default_server.conf.j2

@@ -12,3 +12,10 @@ server {
         {% include 'roles/sys-front-tls/templates/acme.conf.j2' %}
     {% endif %}
 }
+
+server {
+    listen 443 ssl default_server;
+    listen [::]:443 ssl default_server;
+
+    ssl_reject_handshake on;
+}