🐛 BUG: Deploy to Cloudflare button fails with misleading "problem parsing the Wrangler configuration file" when package.json cloudflare metadata has empty preview_image_url

> [!NOTE]
> **Updated after systematic bisection — the original report below the fold blamed `instance_type: "standard-4"`, which turned out to be wrong.** The actual root cause is in `package.json` template metadata, and the error message misattributes it to the Wrangler config file.

### Root cause

The Deploy to Cloudflare button (`POST /api/v4/workers/template-from-worker`, returns 400) fails when `package.json`'s `"cloudflare"` template-metadata block contains an **empty `"preview_image_url": ""`** — and the dashboard reports it as:

> There was a problem parsing the Wrangler configuration file. Please raise an issue in the Workers SDK repo.

The Wrangler config file is not the problem. That misattribution sent us down a long false trail.

### Bisection evidence

All tests run against fresh paths of the same public repo (`tombeckenham/hyperframes-cloudflare-template-tom`), each path a distinct subdirectory so results couldn't be cached (see caching note below):

| Test | Contents | Result |
|---|---|---|
| official `containers-template` verbatim | — | ✅ pass |
| official + this template's full `wrangler.jsonc` (`containers`, Dockerfile image, `standard-4`-equivalent custom instance type, custom build, assets, R2, vars) | config exercised alone | ✅ pass |
| official + this template's `package.json` | metadata exercised alone | ❌ fail |
| same, wrangler devDependency pinned `4.88.0`, no lockfile | rule out wrangler version resolution | ❌ fail |
| same, `"cloudflare"` block deleted | | ✅ pass |
| official + only the `"cloudflare"` block transplanted | converse | ❌ fail |
| block with `"preview_image_url": ""` **removed** (empty `"icon_urls": []` kept) | | ✅ **pass** |
| block with `"icon_urls": []` removed, `"preview_image_url": ""` kept | | ❌ **fail** |
| full app, original `wrangler.jsonc` with `instance_type: "standard-4"`, only `preview_image_url` removed | end-to-end | ✅ **pass** |

So: `"preview_image_url": ""` (empty string) → hard failure with a misleading error. `instance_type: "standard-4"` and the rest of the config are fine. Empty `"icon_urls": []` is fine.

### Reproduction

Any public repo whose `package.json` contains:

```json
"cloudflare": {
"label": "...",
"preview_image_url": ""
}
```

opened via `https://deploy.workers.cloudflare.com/?url=` shows the "problem parsing the Wrangler configuration file" error.

### Suggested fixes

1. Treat an empty/missing `preview_image_url` as "no preview image" instead of failing (it's easy to end up with `""` when scaffolding metadata).
2. If it must be rejected, say so: "Invalid `cloudflare.preview_image_url` in package.json" — not a Wrangler-config parse error pointing at the wrong file.

### Secondary issue: verdict caching makes this near-impossible to debug

The parse verdict appears to be cached per repo/path for at least ~30 minutes, ignoring new commits. Concretely: after a path had passed once, we committed a deliberately **corrupted** `wrangler.jsonc` (unbalanced braces) to that path and the flow still showed the passing configure step; conversely a failing repo kept failing across many fix commits. Anyone iterating on a template fix will conclude their fixes don't work. A cache key including the commit SHA (or a shorter TTL) would fix this.

---

Original (incorrect) report — kept for history

The original report reproduced the same dashboard error on `heygen-com/hyperframes-cloudflare-template` and, based on old wrangler versions locally rejecting `"instance_type": "standard-4"` (`wrangler@4.40.0`: `Expected "containers.instance_type" field to be one of ["dev","basic","standard"]`), concluded the server ran an outdated config schema. That local repro was a coincidence: the server-side failure was the empty `preview_image_url` in `package.json` all along (that repo has both). Environment: macOS 26.5, Node 25.9.0, wrangler 4.85–4.114 all deploy the config fine via CLI.

Comienza con el bloque cloudflare template-metadata de package.json y reproduce el fallo mediante POST /api/v4/workers/template-from-worker o la URL Deploy to Cloudflare. Verifica el comportamiento con una preview_image_url vacía o ausente e inspecciona el comportamiento de caché de veredictos descrito en el informe. Se considera terminado cuando los metadatos ya no provoquen un error engañoso de configuración de Wrangler, o cuando la respuesta identifique claramente el campo no válido de package.json.

Escrito por el modelo de indexación a partir del texto del issue.