Browser Run: Kitesurf says to add browser=kitesurf to any Quick Action, but most Quick Action pages document /browser-rendering/ instead of /browser-run/

### What is the issue?

The Kitesurf page says to add `browser=kitesurf` to "any Quick Action endpoint"
and shows the parameter on `/browser-run/`:

> You can also use Kitesurf with Browser Run's [Quick Actions](/browser-run/quick-actions/). Add `browser=kitesurf` to any Quick Action endpoint.

```
curl -X POST 'https://api.cloudflare.com/client/v4/accounts//browser-run/screenshot?browser=kitesurf'
```

Most of the Quick Actions reference pages document a different base path. Counted
on `main` today:

| page | `/browser-rendering/` | `/browser-run/` |
|---|--:|--:|
| `screenshot-endpoint.mdx` | 8 | 2 |
| `pdf-endpoint.mdx` | 7 | 1 |
| `json-endpoint.mdx` | 5 | 2 |
| `markdown-endpoint.mdx` | 4 | 0 |
| `links-endpoint.mdx` | 4 | 0 |
| `content-endpoint.mdx` | 3 | 0 |
| `scrape-endpoint.mdx` | 2 | 0 |
| `crawl-endpoint.mdx` | 17 | 20 |
| `snapshot.mdx` | 4 | 7 |

So a reader who reaches Quick Actions through the reference pages builds their
call on `/browser-rendering/`, then adds `?browser=kitesurf` because the
Kitesurf page told them to add it to any Quick Action endpoint.

### Why that combination is hard to notice

**Both base paths route**, so the older one produces no routing error. Probed
today, unauthenticated, against a syntactically valid but nonexistent account id:

```
/browser-run/screenshot -> 10000 Authentication error
/browser-rendering/screenshot -> 10000 Authentication error
/browser-nonsense/screenshot -> 7003 Could not route to /accounts/.../browser-nonsense/screenshot
```

The third line is the control: 7003 is what a path that does not route returns,
and neither of the first two gives it.

**And the response carries no engine field.** The documented Quick Action envelope
is `{success, result, meta: {status, title}}`, so an endpoint that honours the
selector and one that ignores it return the same shape. There is no field a
caller can read to confirm the opt-in took effect.

Put together: if `?browser=kitesurf` is not honoured on `/browser-rendering/`,
a reader gets a successful Chromium render, a 200, and no signal at all that they
opted into nothing. That is the failure mode worth a docs fix, because the user
cannot detect it from the response.

### What I am asking

Which base path is canonical for Quick Actions? Two ways this could resolve:

1. `/browser-run/` is canonical and the reference pages are stale. Then those
seven pages want updating, and I am happy to send that PR.
2. Both are supported aliases and the selector works on either. Then the Kitesurf
page is fine, and it would help to say so explicitly, since the two sets of
pages currently disagree about which URL to write.

Either way, a sentence on the Kitesurf page naming the base path the selector
requires would remove the ambiguity.

### One thing I could not verify

Whether `?browser=kitesurf` is actually ignored on `/browser-rendering/`. It was
measured that way on 2026-08-08 by someone I work with, and I have not been able
to re-run it, because telling the two engines apart needs an authenticated render
and the response has no engine field to read. The docs inconsistency above stands
on its own regardless of how that resolves, which is why I am reporting it rather
than waiting.