wrangler r2 bucket list silently returns only the first 20 buckets, with no cursor, warning, or --per-page

### Which Cloudflare product(s) does this pertain to?

Wrangler core, R2

### What version(s) of the tool(s) are you using?

4.120.0 (also reproduced on 3.79.0)

### What version of Node are you using?

22

### What operating system and version are you using?

macOS 15 (Darwin 25.5.0, arm64)

### Describe the Bug

`wrangler r2 bucket list` silently returns only the first **20** buckets, with no cursor, no "more results" indicator, no warning, and no flag to raise the page size. On an account with more than 20 buckets, the output is a truncated list that is indistinguishable from a complete one.

This is a quiet-wrong failure rather than a loud one, and it has a genuinely destructive natural consequence: if a bucket does not appear in the list, the obvious next step is to create it. On our account that would have meant creating a bucket over the top of one already holding 3.41 GB of live user-uploaded media.

**The API is not the limitation.** The same account, same credentials:

```
GET /client/v4/accounts/$ACCOUNT/r2/buckets?per_page=20 -> 20 buckets
GET /client/v4/accounts/$ACCOUNT/r2/buckets?per_page=100 -> 45 buckets
```

So the account genuinely has 45 buckets. Wrangler requests the default first page and presents it as the whole set.

Two smaller notes that make it harder to notice:

- The listing is alphabetical, so the omitted buckets are always the ones latest in the alphabet. Ours cut off at `petrol-now-bucket-prod`, and everything from `q` to `z` was invisible, including `whisp-earth-production`.
- The response body carries no `result_info`, so there is nothing in the payload a caller could inspect to detect truncation even if they wanted to.

### Please provide a link to a minimal reproduction

No public repro link, since it requires an account with more than 20 R2 buckets. The reproduction is fully specified below.

### Steps to reproduce

1. Use an account with more than 20 R2 buckets.
2. Run `wrangler r2 bucket list`.
3. Count the results: exactly 20, sorted alphabetically.
4. Query the API directly with `per_page=100` and observe the true count.
5. Confirm a missing bucket really exists and is reachable with the same credentials:

```
$ wrangler r2 object get whisp-earth-production/definitely-not-a-real-key --file=/dev/null
✘ [ERROR] The specified key does not exist.
```

A *key*-level error proves the bucket resolved. The bucket was never missing, was never a permissions problem, and was reachable the entire time it was absent from `bucket list`.

### Expected behaviour

Either of these would resolve it:

1. **Paginate to completion by default**, following the cursor until exhausted, so `bucket list` means what it says.
2. If that is undesirable for very large accounts, **expose `--per-page` / `--cursor`** and **print an explicit truncation notice** when more results exist, e.g. `showing first 20 of N buckets`.

Option 1 matches what users assume the command already does. Option 2 is acceptable as long as the truncation is visible, because the current failure mode is silent.

### Additional context

Three separate people on our team reached the same wrong conclusion from this output on the same day, by three different routes, before someone checked the dashboard and found the bucket sitting there with 501 objects in it.

Start by reproducing `wrangler r2 bucket list` against an account with more than 20 R2 buckets, then compare its output with the API request using `per_page=100`. Trace the implementation behind the bucket-list command and its tests, if present; done means all buckets are returned or any truncation is explicit and actionable.

Written by the indexing model from the issue text.