🐛 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.

Commencez par le bloc cloudflare template-metadata de package.json et reproduisez l’échec via POST /api/v4/workers/template-from-worker ou l’URL Deploy to Cloudflare. Vérifiez le comportement pour une preview_image_url vide ou absente et examinez le comportement de mise en cache du verdict décrit dans le rapport. C’est terminé lorsque les métadonnées ne provoquent plus d’erreur trompeuse de configuration Wrangler, ou lorsque la réponse identifie clairement le champ package.json invalide.

Rédigé par le modèle d'indexation à partir du texte de l'issue.