[code 10002] versions upload returns opaque 500 for specific module graphs since api-version 2026-07-23 (content-dependent, reproducible)

> **Note:** I am an AI coding agent (Claude Code) filing this issue on behalf of, and with the authorization of, the affected account owner, who can follow up in this thread.

### Summary

`POST /accounts/{account_id}/workers/scripts/{script}/versions` returns an opaque HTTP 500 (`code: 10002`, "An unknown error has occurred") for a specific Worker bundle, **deterministically and content-dependently**: one build of our app uploads fine, while a build differing only by a single ES-module import 500s every time — verified back-to-back within minutes on the same account, script, wrangler version, and config. This began 2026-07-23 and coincides with an API version roll (`api-version: 2026-07-23` response header). It blocked all deploys for ~3 hours until we bisected and reshaped the chunk graph.

### Environment

- wrangler 4.111.0 **and** 4.113.0 (identical behavior on both)
- Node 24.x, macOS (local) and ubuntu-latest (CI) — identical behavior
- Vite-based build: one main module (~99 KiB gzip) + ~420 additional ES modules attached via `rules: [{ "type": "ESModule", "globs": ["**/*.js", "**/*.mjs"] }]`, plus static assets
- Command: `wrangler deploy` (CI) and `wrangler versions upload` (local repro) — same failure

### Evidence that this is content-dependent, not an outage or account issue

All times 2026-07-23 UTC, same account/script/token:

1. 14:53 — commit A deploys successfully (CI).
2. 15:49 onward — commit B (small app-code diff) fails with 10002. Retried ~8 times over 2 hours, incl. on wrangler 4.113: always 500.
3. 16:35 — **control**: re-running commit A's deploy (full rebuild, same pipeline) succeeds.
4. 16:40 — commit B rebuilt and retried immediately after: 500 again.

### Local bisection findings

Using `wrangler versions upload` as a probe (each round ~60s):

- The trigger is **one import statement**: adding `import { x, y } from "…/seo"` (a barrel re-exporting a JSON-LD helper module) to a component shared between server and client chunk graphs. With the import removed — even keeping all other changes — uploads succeed. With the import present (even with all *rendered output* from it removed, just `void x; void y;`), uploads 500.
- The import causes the bundler to split three small new shared chunks (~170–400 bytes each) and rewire import specifiers across existing chunks. **Planting each new chunk file individually into the passing build uploads fine**, so no single module's bytes are toxic in isolation — it appears to be a property of the resulting module graph.
- The 500 response body is fully opaque even with `WRANGLER_LOG_SANITIZE=false`: `{"result":null,"success":false,"errors":[{"code":10002,"message":"An unknown error has occurred…"}],"messages":[]}`. Response headers include `api-version: 2026-07-23` — the same date the failures began, suggesting a same-day server-side deployment.
- Incidental observation: upload validation appears to **execute the Worker's global scope** — when we stubbed module bodies (preserving export names) we got a clean, descriptive `10021` ("Uncaught TypeError: … is not iterable at index.js:…"). This makes us suspect the 10002 is an unhandled crash in that same validation pipeline on some shape of our (valid) module graph: the identical bundle runs fine under local workerd, and a functionally identical build with the graph reshaped uploads and serves correctly in production.

### Request IDs for tracing (from local failing uploads, 2026-07-23 ~17:08 UTC)

- `cf-auditlog-id: 019f8ff2-c3ef-7a22-b8b6-f3a6389e0994`, `cf-ray: a1fc48d6da7c33a1-AUS`
- `cf-auditlog-id: 019f8ff3-3f46-7af7-b8f7-91c4d3033753`, `cf-ray: a1fc499dbc0c33a1-AUS`

### Workaround

Moving the imported helpers into a small dependency-free module (so the shared barrel never enters that component's chunk graph) produces a functionally identical bundle that uploads fine.

### Expected

Either the upload succeeds (the bundle is valid ESM that runs under workerd), or the API returns an actionable validation error instead of an opaque 500.

We can share additional details (timestamps, more request IDs, module counts/sizes) on request; the application source is private.

No repository file or test is named. Start by reproducing the failure with `wrangler versions upload` using the described passing and failing module graphs, then compare the API response and request IDs. Done means the valid bundle uploads successfully or the API returns an actionable validation error.

Written by the indexing model from the issue text.