fix(api): explain why Cloudflare refused a request

[mattzcarey]

Second of five stacked PRs, on #247. Replaces #260 (same change, ported onto the Forge artifacts).

Cloudflare answers three different problems with the same 403:

• the OAuth grant lacks the scope
• the endpoint isn't available to OAuth at all (billing, API tokens)
• the user's role doesn't allow it (OAuth Full Access grant returns error 10000 for Rulesets GET endpoints #199, OAuth grant with DNS Read cannot list zone DNS records (error 10000) — zones list works #202)

execute reduced all three to Cloudflare API error: 10000: Authentication error. Agents read that as a signed-out connection, ask the user to reconnect, get the same error, and ask again. This PR makes the tool result say which case it is.

Before
Error: Cloudflare API error: 10000: Authentication error

After
Error: Cloudflare API error: GET /zones/023e…/dns_records returned HTTP 403: 10000: Authentication error
(https://developers.cloudflare.com/api/resources/dns/subresources/records/). This connection was not
granted a scope this endpoint accepts. Reconnect and grant one of: `dns.read` (DNS Read), `dns.write` (DNS Write).

Connection	Endpoint accepts	Next step
OAuth, holds none of the accepted scopes	dns.read, dns.write	Reconnect and grant one of them
OAuth, holds dns.read	dns.read, dns.write	Reconnecting won't help: check the role or the granted accounts
OAuth	Billing Read (no OAuth scope)	Use an API token with Billing Read
API token or direct Cloudflare OAuth token	DNS Read, DNS Write	The token needs one of these
Any	nothing in the spec	HTTP 403 isn't a sign-in problem; check the docs

• What the endpoint accepts: Forge's x-api-token-group lists the API token permissions an operation accepts, and OAuth scopes use the same names.
  • The build now keeps it in spec.json (scripts/generator/spec.ts), so search can show it too.
  • Endpoint tools already carry it in their mcp-tools.json entry, and use that entry's permissions and path template.
  • execute parses spec.json paths only when a request is refused (getSpecPaths()), and reuses the result until the cached text changes.
• Which connection it is: ctx.auth from workers-oauth-provider now reaches the tools as a Connection. A token the provider issued carries clientId and scope (oauth). A credential resolved by resolveExternalToken carries neither (direct).
• execute: GlobalOutbound looks the permissions up only for a 401 or 403 and returns the explanation in X-Cloudflare-MCP-Refusal-Hint. The sandbox adds it to the thrown error, along with the method, path, status and documentation_url. That way it survives code that catches the error.
• Endpoint tools: errors now start with Cloudflare API error: GET /path returned HTTP 403. The explanation follows the response body.

Next in the stack: #268, 403 insufficient_scope challenges, so clients that support step-up can ask for the missing scope themselves.