auditlogs_by_account_id: zod validation fails on actor.context == "api" (new value from Cloudflare API)

### Client Information
- LLM Client: Claude Code CLI
- MCP Server: https://auditlogs.mcp.cloudflare.com/mcp
- Using MCP Remote?: No (remote HTTP MCP)
- Prompt: Weekly SOC 2 continuous-monitoring checkpoint — query audit logs for a 7-day window

### Describe the bug
`auditlogs_by_account_id` returns **13 zod validation errors** and no data for a 7-day window on a low-activity account. The response schema for `actor.context` is declared as:

```ts
// apps/auditlogs/src/tools/auditlogs.tools.ts:9
export const actorContexts = z.enum(['api_key', 'api_token', 'dash', 'oauth', 'origin_ca_key'])
```

…but the live Cloudflare Audit Log API is now returning `actor.context = "api"` for many entries (appears to indicate a generic API-driven change, distinct from `api_key` / `api_token`). Every entry with this value fails validation, which causes the whole response to be rejected — even though the entries themselves are legitimate.

### Error (trimmed — 13 identical errors at different result indices)
```json
{
"received": "api",
"code": "invalid_enum_value",
"options": ["api_key", "api_token", "dash", "oauth", "origin_ca_key"],
"path": ["result", 2, "actor", "context"],
"message": "Invalid enum value. Expected 'api_key' | 'api_token' | 'dash' | 'oauth' | 'origin_ca_key', received 'api'"
}
```

### To reproduce
1. Connect to `https://auditlogs.mcp.cloudflare.com/mcp`
2. Call `auditlogs_by_account_id` with any 7-day window that contains API-driven activity:
```json
{
"since": "2026-04-10",
"before": "2026-04-17",
"limit": 100
}
```
3. All entries where the platform returns `actor.context = "api"` fail the enum check; the tool returns no data.

### Expected behavior
The tool returns the audit log entries. The response schema should accept `"api"` as a valid `actor.context` value (or relax `actorContexts` to `z.string()` since Cloudflare's API evolves and the current enum is already incomplete).

### Proposed fix (one-line change)
In [`apps/auditlogs/src/tools/auditlogs.tools.ts:9`](https://github.com/cloudflare/mcp-server-cloudflare/blob/main/apps/auditlogs/src/tools/auditlogs.tools.ts#L9):

```diff
-export const actorContexts = z.enum(['api_key', 'api_token', 'dash', 'oauth', 'origin_ca_key'])
+export const actorContexts = z.enum(['api', 'api_key', 'api_token', 'dash', 'oauth', 'origin_ca_key'])
```

A more defensive alternative would be to drop the enum entirely on the **response** side and keep it only on the **query filter** side (`auditLogsQuerySchema.actor_context`), since Cloudflare's response surface clearly isn't a closed set.

### Additional context
- Same class of bug as #270 (also open, also an over-strict response schema — `resource.response` array vs object). Both point to the response schema being written too tightly against a particular snapshot of the Cloudflare API.
- The underlying Cloudflare API call succeeds (HTTP 200 upstream); only the MCP-side response validation fails.
- `accounts_list` works fine on the same MCP session, so this is specific to the response schema in `auditlogs.tools.ts`, not auth or transport.
- This is currently blocking a SOC 2 Type II continuous-monitoring control; happy to test a fix against our account if helpful.