Workers environments: staging and production from one config

# Wrangler environments

One Wrangler file, multiple deployments. Environments override top-level config per named environment.

```jsonc
{
  "name": "my-worker",
  "route": "dev.example.com/*",
  "vars": { "ENVIRONMENT": "dev" },
  "env": {
    "staging": {
      "vars": { "ENVIRONMENT": "staging" },
      "route": "staging.example.com/*"
    },
    "production": {
      "vars": { "ENVIRONMENT": "production" },
      "routes": ["example.com/*"]
    }
  }
}
```

Deploy with `wrangler deploy --env staging`. The Worker name becomes `my-worker-staging` (name plus env suffix), and each environment can carry its own routes, KV namespaces, D1 databases, and other bindings.

## The traps

- **`vars` are non-inheritable.** Top-level `vars` do not flow into environments; every environment must define its own. The config above repeats `ENVIRONMENT` in each env for exactly this reason.
- **Custom domains and routes need per-env values.** If you deploy to a custom domain or route, each environment needs its own `route`/`routes` key. A staging deploy without one goes to `workers.dev` (or fails, depending on the rest of the config).
- **`workers_dev` per environment.** To give staging a `*.workers.dev` subdomain, set `workers_dev = true` inside that environment's block.
- **With the Vite plugin**, select the environment with `CLOUDFLARE_ENV`, not `--env`; the build flattens to a single config for that environment.

## Checklist

- Give each environment its own backing resources (separate KV namespaces, D1 databases); sharing production data with staging is how staging writes end up in prod.
- `wrangler dev --env staging` for local work against the staging config.
- Name environments `staging` and `production`, not `dev2` and `final`; future you will thank present you.