Named/staging environments not serving TLS on West US 2 scale unit 7 (*.westus2.7.azurestaticapps.net) — 0-byte handshake

### Summary

Named/staging-environment hostnames on **West US 2 Static Web Apps scale unit 7** are not completing TLS handshakes. The endpoint accepts the TCP connection, receives the ClientHello, and returns **zero bytes** — no ServerHello, no certificate, no TLS alert. Browsers report `ERR_CONNECTION_CLOSED`. This affects the named-environment hostnames of **multiple, independent Static Web Apps**; their **default (production) environments**, and apps on **other scale units (e.g. West US 2 slice 4)**, are unaffected.

### Affected — named/staging hostnames (all failing)

- `kind-glacier-0ed8e761e-preview.westus2.7.azurestaticapps.net`
- `kind-glacier-0ed8e761e-production.westus2.7.azurestaticapps.net`
- `calm-ground-082647c1e-preview.westus2.7.azurestaticapps.net` *(a different Static Web App)*

### Working — contrast

| Host | Note |
|---|---|
| `kind-glacier-0ed8e761e.7.azurestaticapps.net` | default env, slice 7 — **works** |
| `calm-ground-082647c1e.7.azurestaticapps.net` | default env, slice 7 — **works** |
| `agreeable-beach-0070f6b1e-preview.westus2.4.azurestaticapps.net` | staging env on slice **4** — **works** |

So: default environments on slice 7 work; only **named/staging** environments on slice 7 fail; a staging environment on **slice 4** works. The failure tracks the **slice-7 West US 2 staging TLS endpoint**.

### Evidence

`openssl s_client` to a failing host — **no certificate served**:

```
$ echo | openssl s_client -connect kind-glacier-0ed8e761e-preview.westus2.7.azurestaticapps.net:443 \
-servername kind-glacier-0ed8e761e-preview.westus2.7.azurestaticapps.net
CONNECTED(00000003)
no peer certificate available
SSL handshake has read 0 bytes and written 1607 bytes
New, (NONE), Cipher is (NONE)
```

`openssl s_client` to a working slice-4 host — certificate served normally:

```
subject=... CN=*.westus2.4.azurestaticapps.net
issuer=C=US, O=Microsoft Corporation, CN=Microsoft TLS G2 RSA CA OCSP 02
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
```

This shows the managed wildcard certificate is **per scale unit** (`*.westus2.4…`); the `*.westus2.7.azurestaticapps.net` equivalent is not being served.

DNS of the failing host resolves via `azurestaticapps7-wus2.trafficmanager.net` → `msha-slice-7-wus2-1.msha-slice-7-wus2-1-ase.p.azurewebsites.net`.

### Already ruled out

- **DNS / TCP** — resolves and connects on 443.
- **Client / network** — same client reaches the default hosts and the slice-4 host fine (HTTP 200).
- **Certificate validation / expiry** — no certificate is served at all (0-byte handshake).
- **Failed deployment** — deployments succeed; environment status = `Ready`.
- **Environment recreate** — deleting and recreating the named environment produces a fresh environment that **still serves no certificate**.

### Impact

Preview/QA environments for two applications are unreachable. Production (default) environments are unaffected.

### Ask

Please investigate the managed TLS endpoint for **West US 2 Static Web Apps scale unit 7** (staging wildcard `*.westus2.7.azurestaticapps.net`, edge `msha-slice-7-wus2-1`) — it accepts TCP but returns a 0-byte TLS handshake with no certificate. Is this a known regional issue, and is there an ETA?

Start by reproducing the TLS failure with the listed openssl s_client command against the slice-7 named-environment hosts, then compare it with the working default and slice-4 hosts. Investigate the managed TLS endpoint at msha-slice-7-wus2-1 and the *.westus2.7 certificate path. Done means identifying the regional cause or confirming it as a known issue and providing an ETA or remediation.

Written by the indexing model from the issue text.