[Bug]: Custom loopback address is not applied to HTTPS listeners for secured sites

Expected secured site config:

```nginx
listen 127.0.0.1:443 ssl;
listen :443 ssl; # valet loopback
```

Actual secured site config:

```nginx
listen 127.0.0.1:443 ssl;
#listen VALET_LOOPBACK:443 ssl; # valet loopback
```

The real-world use case is local-device HTTPS testing:

- Herd runs on a Mac.
- A local DNS server such as Namo, dnsmasq, Pi-hole, Technitium DNS, AdGuard Home, or router DNS overrides resolves `*.test` domains from other devices on the same LAN.
- Physical iPhones, iPads, and Android devices load the Herd site through the configured loopback address.

This is useful for testing HTTPS-only browser and device behaviour, including passkeys, WebAuthn, secure cookies, Service Workers, PWAs, camera and microphone APIs, Mobile Safari behaviour, Apple Pay where applicable, and other secure-context browser APIs.

The issue appears to be in secure config generation. The live Herd CLI runs from:

```text
~/Library/Application Support/Herd/bin/herd.phar
```

Inside that PHAR, the secure templates had the HTTPS loopback listener commented, and `Site.php` only matched the older Nginx 443 listener syntax:

```nginx
listen ...:443 ssl http2;
```

Current secure configs use:

```nginx
listen ...:443 ssl;
http2 on;
```

So the configured loopback value passed into `replaceOldLoopbackWithNew()` is not reliably substituted and uncommented for HTTPS listeners.

A generic fix should:

- use the configured Herd loopback value, never a hard-coded address
- enable the HTTPS loopback placeholder in both secure templates
- support port 80, port 443, and port 60 loopback listener lines
- support both `listen ... ssl;` plus `http2 on;` and legacy `listen ... ssl http2;`
- preserve indentation and handle an optional leading comment marker
- comment loopback listeners only when the configured loopback is the default `VALET_LOOPBACK`
- apply to normal secured sites and secure proxy sites

### Steps to reproduce

1. Configure Herd with a custom loopback address, for example:

```shell
herd loopback 192.168.1.50
```

2. Secure a normal Herd site:

```shell
herd unsecure example
herd secure example
```

3. Inspect the generated Nginx config:

```shell
grep -n "listen.*443\|VALET_LOOPBACK" "$HOME/Library/Application Support/Herd/config/valet/Nginx/example.test"
```

Expected:

```nginx
listen 127.0.0.1:443 ssl;
listen :443 ssl; # valet loopback
```

Actual:

```nginx
listen 127.0.0.1:443 ssl;
#listen VALET_LOOPBACK:443 ssl; # valet loopback
```

4. Repeat with a secure proxy site:

```shell
herd proxy proxy-example http://127.0.0.1:8000 --secure
```

The secure proxy template path has the same issue.

### Relevant log output

```shell
Runtime values observed during local investigation:

$old = VALET_LOOPBACK
$new = configured Herd loopback address
$this->valetLoopback() = configured Herd loopback address
secure template line received before fix = #listen VALET_LOOPBACK:443 ssl; # valet loopback

Validation after local proof-of-concept fix:

grep -n "listen.*443" "$HOME/Library/Application Support/Herd/config/valet/Nginx/example.test"

listen 127.0.0.1:443 ssl;
listen :443 ssl; # valet loopback

lsof -nP -iTCP:443 -sTCP:LISTEN

TCP 127.0.0.1:443 (LISTEN)
TCP :443 (LISTEN)

curl -Ik --resolve example.test:443: https://example.test

HTTP/2 200

Also validated:

- newly secured standard site generated an active configured-loopback HTTPS listener
- newly secured secure proxy site generated an active configured-loopback HTTPS listener
- no literal VALET_LOOPBACK remained on the active HTTPS listener
```