Workers Builds 'fix Worker name' PR ignores documented exemptions (custom deploy command, environments naming, --experimental-autoconfig=false)

### What is the problem?

Workers Builds' automatic "fix Worker name" PR bot (`cloudflare-workers-and-pages[bot]`, [changelog](https://developers.cloudflare.com/changelog/post/2025-02-20-builds-name-conflict/)) repeatedly opens a PR retitling the top-level `wrangler.jsonc`/`wrangler.toml` `name` field to match the connected (anchor) Worker — even when that mismatch is intentional (e.g. one repo with a top-level config for a Worker deployed only via a separate, disconnected deploy path, and an `env.*` block for the Worker Workers Builds actually deploys).

We tested every documented and CLI-level mitigation we could find, and none of them stop the PR:

1. **Custom deploy command** — the [docs](https://developers.cloudflare.com/workers/ci-cd/builds/troubleshoot/#workers-name-requirement) state a config PR "is only generated when your deploy command is `npx wrangler deploy`." We use `pnpm exec wrangler deploy -c dist/server/wrangler.json` (functionally equivalent, but not that literal string) — a PR was still opened.
2. **`-` Wrangler-environments naming** — [docs](https://developers.cloudflare.com/workers/ci-cd/builds/troubleshoot/#workers-name-requirement) document an exception where a dashboard Worker `my-worker-staging` can deploy from config `name = my-worker` + `[env.staging]`. We renamed our top-level config to match this shape exactly (top-level `please-corp` + `env.dev` → dashboard Worker `please-corp-dev`) — a PR was still opened.
3. **`--experimental-autoconfig=false`** — `wrangler deploy --help` shows this flag defaults to `true` in wrangler 4.100.0. We appended it to the deploy command — a PR was still opened.

Across all three tests, PR creation consistently landed **~71–75 seconds into every ~3–4 minute build**, well before the deploy step runs. This strongly suggests the name-fix generator is a server-side check that runs early in the build pipeline (post-clone, pre-deploy) — meaning none of the wrangler CLI flags or deploy-command shapes documented as exemptions can actually reach it.

Full evidence and timestamps: https://github.com/cloudflare/workers-sdk/discussions/11667#discussioncomment-17677011

### What is the expected behavior?

Either:
- The documented exemptions (custom deploy command, environments naming) should actually suppress the PR, as the docs state, **or**
- There should be an explicit account/Worker-level toggle to disable this specific PR-bot behavior, independent of `autoconfig` and independent of branch-build settings.

### How can we reproduce it?

1. Connect a Worker `foo-dev` to a repo via Workers Builds, with the git connection anchored to `foo-dev`.
2. In the repo's Wrangler config, set the top-level `name` to something that does NOT match `foo-dev` (e.g. because a *separate*, disconnected Worker `foo-prod` uses that top-level name for its own deploy path), while an `env.dev` block sets `name: "foo-dev"`.
3. Push to the watched branch. Observe the bot opens a PR renaming the top-level `name` to `foo-dev`.
4. Try any of: a custom (non-`npx wrangler deploy`) deploy command, restructuring the config to the `-` exception shape, or `--experimental-autoconfig=false`. Push again. The PR still gets opened.

### Workaround

We ended up blocking the bot's branch (`update_worker_name_to_*`) from being created at all via a GitHub repository ruleset (requires a paid GitHub plan for private repos), and additionally auto-close any PR that does get through via a scoped GitHub Action. Neither of these should be necessary — an account-level toggle would be much simpler.

Commencez par reproduire le flux de Workers Builds en utilisant le nom top-level de wrangler.jsonc/wrangler.toml, un nom env.dev et les variantes de deploy-command indiquées. Consultez la documentation de troubleshooting liée et les horodatages des éléments de preuve, puis suivez l’endroit où le name-fix PR est généré. C’est terminé lorsque les exemptions documentées empêchent la création du PR ou qu’un toggle explicite de désactivation au niveau du compte/Worker est disponible.

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