DNS Analytics MCP: `zone` param requires a zone ID but errors as if the zone is missing; `dns_report` unusable below Business at any window

Two usability bugs in the **DNS Analytics** MCP server (`https://dns-analytics.mcp.cloudflare.com/mcp`), found while using it against a live account. Both are low severity but each costs real debugging time because the failure mode points away from the actual cause.

## 1. `zone` parameter requires a zone **ID**, but is named `zone` and errors misleadingly on a name

`show_zone_dns_settings` and `dns_report` both declare a parameter named `zone` (type `string`). Passing an actual zone **name** produces:

```
404 {"result":null,"success":false,"errors":[{"code":7003,
"message":"Could not route to /client/v4/zones/example.com/dns_settings,
perhaps your object identifier is invalid?"}]}
```

Passing the zone **ID** works correctly and returns the expected payload.

**Why this is confusing:** the sibling tool `zones_list` accepts a `name` filter, so a name feels like the natural identifier for a parameter called `zone`. And the 7003 message — *"perhaps your object identifier is invalid?"* — reads as *this zone does not exist* rather than *you passed the wrong kind of identifier*. The natural next step is to go hunting for a missing zone that is in fact present and active.

**Suggested fixes** (any one):

- rename the parameter to `zoneId` (matching `zone_details`, which already uses `zoneId`), and/or
- state "zone ID, not zone name" in the parameter description, and/or
- accept either and resolve a name → ID internally before the API call.

The inconsistency with `zone_details` — which correctly names its parameter `zoneId` — is what makes this a naming bug rather than just missing docs.

## 2. `dns_report` is unusable on sub-Business plans at **any** window

`dns_report` appears to always request the `responseCached` dimension, which requires the Business plan. On a Pro zone:

```
days: 7 → 403 {"code":1034,"message":"Maximum queryable time period
for the pro plan is 24h0m0s."}
days: 1 → 403 {"code":1034,"message":"Response Cached is not available
for your plan. Upgrade to the business plan to see
DNS analytics by responseCached."}
```

Shortening the window to satisfy the first error just reveals a second, unconditional paywall — so there is no value of `days` that succeeds below Business. The tool is effectively non-functional on Free/Pro rather than degraded.

**Suggested fixes:**

- omit `responseCached` (or request it conditionally) so the tool returns the dimensions the plan does allow, and/or
- surface the plan requirement in the tool description so callers know it needs Business+ before spending calls on it, and/or
- clamp `days` to the plan's maximum queryable window instead of passing it through to a 1034.

## Environment

- Server: `https://dns-analytics.mcp.cloudflare.com/mcp` (http transport)
- Client: Claude Code
- Zones tested: one Pro, one Free, same account
- Both tools otherwise behave correctly when given a zone ID on a sufficiently-privileged plan

Happy to supply request IDs privately if useful — omitting zone IDs here since this is a public tracker.

Start by reading the `show_zone_dns_settings`, `dns_report`, and `zone_details` tool definitions in the DNS Analytics MCP server. Reproduce the reported cases with a zone name versus ID and with Free/Pro plans at the stated `days` values. Done when the parameter communicates or handles the ID requirement clearly, and `dns_report` behaves as intended on plans below Business or states its plan requirement before the call.

Written by the indexing model from the issue text.