fix(lightning): don't let the LNBits Host header break TLS verification

[Danswar]

Problem

GET /v1/lnurlp/:id (and lnurlw/lnurld) started returning 500 on PRD:

Hostname/IP does not match certificate's altnames: Host: api.dfx.swiss. is not in
the cert's altnames: DNS:localhost, DNS:lnd, DNS:vm-dfx-btc-inp-prd..., IP:10.0.1.4

Root cause

#3893 added a Host: <public hostname> header to the LNBits requests so LNBits builds
correct public LNURLs and passes its HTTPS check. But the HTTP client derives the TLS
SNI/servername from that Host header, so Node began validating the node's
self-signed cert against api.dfx.swiss.

On PRD, LND and LNBits are reached over the private IP and serve a cert whose SANs
are localhost / lnd / <vm-dns> / <private-ip> — api.dfx.swiss is not among them, so
every LNURL call failed with ERR_TLS_CERT_ALTNAME_INVALID.

Fix

The cert is already pinned via the ca on the shared agent — that pin is the real
identity guarantee for a private self-signed node, and full chain verification is kept
(rejectUnauthorized stays on). The SAN/hostname match is redundant here and is exactly
what the spoofed Host header poisons, so we skip only the hostname check. The Host
header stays intact for LNBits, and the fix is host-agnostic, so it also holds once
dfxprd reaches LNBits as lnd.

Note / follow-up for review

This drops the hostname check (not chain verification) — a fast, safe unblock for the
live outage. The cleaner long-term fix is to add the public hostname to the node cert
SANs (tlsextradomain=api.dfx.swiss already exists in the dfxprd migration lnd.conf;
the live cert just predates it). Once the cert carries the SAN, this override can be
removed. @davidleomay — flagging since this is your #3893 area; happy to switch to the
SAN approach if you prefer.

[davidleomay]

Approved. Just needs to survive 24h until Azure cutover — on dfxprd LNBits is HTTP so this becomes dead code. Cleanup tracked in DFXServer/server#408.