datasets-server returning 503 (origin awselb) for all datasets for 10+ hours -- viewer down site-wide, status page green

Since roughly 2026-07-13 late morning PT (~18:00 UTC), every `datasets-server.huggingface.co` endpoint we've tried (`/is-valid`, `/splits`, `/first-rows`) returns `503 Service Temporarily Unavailable` (HTML) for every dataset tested, including `rajpurkar/squad` and `stanfordnlp/imdb`. Dataset pages accordingly show "The dataset viewer is not available for this dataset" (verified on `rajpurkar/squad/viewer` in a browser).

Evidence that this is origin-side, not client-side:

- Response headers: `Server: awselb/2.0`, `X-Cache: Error from cloudfront`, `Via: ...cloudfront.net`, POP `LAX53-P6` -- CloudFront reaches the backend and the ALB itself answers 503.
- Reproduced from two fully independent networks (US residential ISP + a datacenter-hosted fetch).
- The Hub itself is unaffected: pages, uploads, downloads, and `huggingface.co/api/*` all work, which is presumably why this is underreported.
- https://status.huggingface.co shows all components Operational throughout the window.

Example (current as of filing):

```
$ curl -si "https://datasets-server.huggingface.co/is-valid?dataset=rajpurkar/squad" | head -8
HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: text/html
Server: awselb/2.0
X-Cache: Error from cloudfront
Via: 1.1 b7b9d4ff5955525f07b19c08b74c752e.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: LAX53-P6
```

Happy to provide full curl traces / `X-Amz-Cf-Id` request IDs if useful.

Start by reproducing the reported 503 responses from the datasets-server endpoints `/is-valid`, `/splits`, and `/first-rows`, including the curl headers and request IDs mentioned in the issue. Check the origin path behind CloudFront and the load balancer; done means these endpoints return their normal API responses and dataset viewer pages load again for the reported datasets.

Written by the indexing model from the issue text.