Dashboard: generic "An unknown error has occurred" toast on Workers service page — GET /builds/builds?version_ids= returns 400 (code 12013)

### What versions & operating system are you using?

N/A — this is a Cloudflare dashboard (dash.cloudflare.com) UI issue, not a Wrangler CLI issue, so `npx envinfo` output isn't applicable. Reproduced in a desktop Chromium-based browser.

### Please provide a link to a minimal reproduction

N/A — dashboard-only, no code repro. Steps are in the description below.

### Describe the Bug

### What happens

Opening the Workers service page in the dashboard (Workers & Pages → a Worker → Overview) sometimes shows the generic red toast:

> An unknown error has occurred. If this error persists, please file a report in workers-sdk (https://github.com/cloudflare/workers-sdk/issues) or reach out to your account team.

The toast carries no error code, no failing endpoint and no request ID, so there is nothing actionable in it for the user. It appeared right after a manual deploy from the dashboard (the page showed the new version as "17 seconds ago").

### What I found in the network tab

Three API calls made by that page returned non-2xx. Two look benign, one looks like a genuine UI bug:

1. `GET /api/v4/accounts//access/organizations` → **403**. Expected: the account has no Zero Trust organisation. Should not surface to the user.
2. `GET /api/v4/accounts//builds/workers/` → **404**, `code: 12040`, "No build configuration associated with that script tag was found for this account". Expected: the Worker is manually deployed and has no Git-connected build configuration. The Deployments tab already handles this gracefully ("No builds exist yet for this worker").
3. `GET /api/v4/accounts//builds/builds?version_ids=` → **400**, `code: 12013`, "Invalid query parameter". **This looks like a race condition in the dashboard's own code:** the request is fired with an *empty* `version_ids` parameter before the version list has resolved, and is then retried successfully once the IDs are available (`?version_ids=%2C` → 200).

### Expected behaviour

* The dashboard should not issue `GET /builds/builds` with an empty `version_ids` list; it should wait until the version IDs are available (or short-circuit when the list is empty).
* Expected/handled failures (403 on `access/organizations`, 404 `12040` for Workers with no build configuration, 400 `12013`) should not trigger the generic "unknown error" toast.
* If a toast must be shown, it should include the failing endpoint / error code / request ID so the report is actionable.

### Notes

* Nothing is actually broken: the active deployment is healthy, carries 100% of traffic and the Worker serves correctly.
* The toast did **not** reproduce on a plain page reload or when navigating to the Deployments tab, which is consistent with a timing-dependent race that is most likely to be hit immediately after a fresh deploy.
* Account ID and script tag are redacted above but I'm happy to share them privately if that helps.

### Please provide any relevant error logs

Raw API responses (fetched from the same page, account ID and script tag redacted):

```
GET /api/v4/accounts//builds/workers/
404
{"success":false,"messages":[],"errors":[{"code":12040,"message":"No build configuration associated with that script tag was found for this account"}],"result":null}

GET /api/v4/accounts//builds/builds?version_ids=
400
{"success":false,"messages":[],"errors":[{"code":12013,"message":"Invalid query parameter"}],"result":null}

GET /api/v4/accounts//access/organizations
403
```

Browser console (from the dashboard's own bundle, `cf-init-core.*.js`), logged twice a couple of seconds apart at around the time the toast appeared:

```
Error checking domains Object
Error checking domains Object
```

Everything else the page requested (workers/services, deployments, versions, script-settings, routes, domains/records, schedules, bindings, subdomain, graphql) returned 200, including the retried `?version_ids=%2C` call.

Start at the Workers service Overview page and trace the request flow visible in the dashboard's cf-init-core.*.js bundle, focusing on GET /builds/builds?version_ids=. Reproduce immediately after a dashboard deploy and inspect the network responses. Done means an empty version_ids request is avoided or safely short-circuited, expected 403/404/400 responses do not trigger a generic toast, and any displayed error is actionable.

Written by the indexing model from the issue text.