Single app wedged: deploys fail at content distribution AND ARM management calls time out with GatewayTimeout from Microsoft.Web (Central US, Free)

### Summary

A single Static Web App (`datum-swa`, Central US, Free tier) has been unable to deploy since ~2026-07-28 22:12 UTC. Every deployment fails at the content-distribution step with:

```
✖ We are currently experiencing problems communicating with our content server.
Please try again later or file an issue if this behavior continues.
✖ Deployment failed with exit code 1.
```

The site itself is completely healthy and serving the previously deployed build (HTTP 200, ~340 ms). Only publishing updates is broken.

Critically, **the ARM management plane cannot read the resource either**, which suggests this is an instance-level fault rather than a content or configuration problem:

```
$ az staticwebapp show -n datum-swa -g datum-rg
ERROR: (GatewayTimeout) The gateway did not receive a response from 'Microsoft.Web'
within the specified time period.

$ az staticwebapp environment list -n datum-swa -g datum-rg
ERROR: (GatewayTimeout) The gateway did not receive a response from 'Microsoft.Web'
within the specified time period.
```

Both calls time out consistently (reproduced 4+ times, 120 s timeout). Meanwhile generic ARM calls against the same subscription and resource group return instantly:

```
$ az group show -n datum-rg # instant, provisioningState=Succeeded
$ az resource list -g datum-rg # instant, lists datum-swa among others
```

So ARM's resource index knows the app exists, but the `Microsoft.Web` provider cannot serve it.

### Environment

| | |
|---|---|
| App name | `datum-swa` |
| Region | Central US |
| SKU | Free |
| Deploy method | `@azure/static-web-apps-cli@2.0.10` (pinned) via GitHub Actions |
| StaticSitesClient | `689a6c1fe8fc32f40348cc41223a7e9d83dd43d2` (downloaded successfully) |
| Payload | 28 MB, 502 files |
| First failure | 2026-07-28 ~22:12 UTC |
| Last known good deploy | 2026-07-28 17:27 UTC (same pipeline, same config, comparable payload) |

### What has been ruled out

- **Our build** — the build step succeeds every time; failure is strictly at the Azure handoff.
- **Our config** — `staticwebapp.config.json` is valid JSON, 12 well-formed routes. The CLI logs `Found configuration file` and proceeds past it. An invalid config fails fast with a schema error; this hangs ~3 minutes then times out.
- **Payload size** — 28 MB / 502 files, essentially unchanged from the deploys that succeeded hours earlier the same day.
- **CLI version** — pinned to an exact version; the StaticSitesClient binary downloads fine.
- **Transient** — three consecutive attempts over ~30 minutes failed identically.

### Timeline (UTC, 2026-07-28)

| Time | Event |
|---|---|
| 17:27 | Deploy succeeds normally |
| 22:12 | Attempt 1 — fails at content distribution after ~4 min |
| 22:19 | Attempt 2 — fails identically after ~5 min |
| 22:59 | Attempt 3 — fails identically |
| throughout | `az staticwebapp show` / `environment list` time out with GatewayTimeout |
| throughout | Site serves normally; all other resources in the subscription respond instantly |

### Note

This is the same failure signature as #1772 / #1773 / #1774 (2026-07-21) and #1777 (2026-07-23), but I can find no other reports today, and Azure status is green — consistent with a single wedged app instance rather than a regional event.

Happy to provide the subscription ID and correlation details privately if that helps locate the resource.

Start by reproducing `az staticwebapp show` and `az staticwebapp environment list` for `datum-swa`, then compare the failed content-distribution deployment with the last successful run. The report points to the Azure `Microsoft.Web` management plane; done means those calls return and a comparable deployment succeeds.

Written by the indexing model from the issue text.