Email Service: GET /accounts/{id}/email/sending/feedback returns 10001 'Unable to authenticate request' despite token working for all other email/sending endpoints

## Which Cloudflare product(s) does this impact?

Email Service (public beta)

## What versions & operating system are you using?

Testing via direct REST API calls using a Cloudflare API token. Workers runtime is incidental to this report.

## Describe the Bug

The `GET /accounts/{account_id}/email/sending/feedback` endpoint returns `[10001] Unable to authenticate request` on an account where the same API token successfully authenticates against every other Email Service endpoint in the same scope group.

### What works with the token

All of these return 200 OK with valid data:

- `GET /accounts/{account_id}/email/sending/limits` → returns `{quota:{value:1000,unit:"day"}}`
- `POST /accounts/{account_id}/email/sending/send` → delivers email, returns delivery status
- `GET /zones/{zone_id}/email/sending/subdomains` → lists configured subdomains
- `POST /zones/{zone_id}/email/sending/subdomains/preview` → returns DNS preview
- `POST /zones/{zone_id}/email/sending/subdomains` → creates subdomain + DNS records
- `GET /zones/{zone_id}/email/sending/subdomains/{id}` → returns subdomain record
- `GET /zones/{zone_id}/email/sending/subdomains/{id}/dns` → returns DNS records
- `GET /accounts/{account_id}/email/sending/suppression` → returns suppression list (empty in our case)

### What fails

Only `GET /accounts/{account_id}/email/sending/feedback`:

```
HTTP/1.1 response body:
{
"success": false,
"errors": [{"code": 10001, "message": "Unable to authenticate request"}],
"messages": [],
"result": null
}
```

### Things ruled out as the cause

1. **Token permissions** — the same token successfully hits `send`, `suppression`, `limits`, `subdomains` and their mutations. It's not a missing Email Service scope.
2. **Missing query params** — the OpenAPI schema lists `start_at` and `end_at` as optional. Tried with both (valid ISO 8601 date range for last 24h) and without. Response is identical.
3. **Account billing/feature tier** — send works, which is the gated premium feature per the beta announcement.
4. **Endpoint path typo** — path matches the OpenAPI schema at `cloudflare/api-schemas` exactly.
5. **`bearerAuth` security scheme differences** — the OpenAPI spec tags `feedback` and `suppression` both with `bearerAuth` + `tags: ["Public"]`. `suppression` works, `feedback` doesn't. Same scheme, same tag group.

### Suspected cause

The `feedback` endpoint appears to be gated behind a separate beta flag (or separate permission scope not yet surfaced) that isn't enabled on accounts that otherwise have Email Service fully enabled. The 10001 suggests the auth token is recognised but rejected at an additional permission check.

## Repro

1. Generate a Cloudflare API token with Email Service: Edit permission
2. Configure a sending subdomain on any zone in the account
3. Successfully send an email via `POST /accounts/{id}/email/sending/send` to prove auth works
4. Call `GET /accounts/{id}/email/sending/limits` — returns 200
5. Call `GET /accounts/{id}/email/sending/suppression` — returns 200
6. Call `GET /accounts/{id}/email/sending/feedback` — returns 10001

## Please provide a link to a minimal reproduction

Not easily reproducible publicly — requires a CF account with Email Service beta access. Happy to provide account ID via direct contact if useful.

## Please provide any relevant error logs

```
{
"success": false,
"errors": [{"code": 10001, "message": "Unable to authenticate request"}],
"messages": [],
"result": null
}
```

Identical response with or without `?start_at=&end_at=` query params.

## Expected behaviour

Either:
- Return 200 with feedback events (possibly empty array for new accounts), or
- Return a more specific error code indicating which additional permission / beta flag is required (e.g. "feature not enabled on this account", or a permission missing error naming the specific scope)

The current 10001 is misleading because the token IS authenticating — just not for this one endpoint. Improved error messaging would save future debugging time for anyone else hitting this.

---

Filed from [jezweb/mcp-packages#356](https://github.com/jezweb/mcp-packages/pull/356) where we've integrated Email Service into our MCP server fleet. All 13 other Email Service actions work flawlessly — this is the only gap.