Feature request: tool call middleware hook for authorization and cross-cutting concerns

### What is the feature or problem you’d like to solve?

There is no hook to intercept tool calls before handler execution. Cross-cutting concerns — authorization, audit logging, argument validation — must be hardcoded into individual tool handlers or require forking the server.

### Why do you need this feature?

Teams deploying these servers in multi-tenant or regulated environments need to enforce per-tool authorization policies and log invocations for compliance without modifying handler code. The existing `DENIED_COMMANDS` mechanism shows the need already exists — a middleware hook generalizes it across all servers in the repo and makes it extensible without touching server internals.

Cloud Audit Logs and IAM operate at the GCP API layer — they record what executed and whether the caller had permission. A middleware hook operates at the MCP tool call boundary, one layer earlier, where per-agent context is available that IAM cannot see: which agent made the request, what task it was assigned, what delegation chain authorized it. Two agents sharing the same service account are indistinguishable to IAM but distinguishable to middleware.
Without this, every team reimplements the same interception logic in their own fork with no interoperability between implementations.

### Example prompts, workflows, or additional information

A middleware interface registered at server startup:
```typescript
interface ToolMiddleware {
beforeToolCall(
toolName: string,
arguments: Record,
meta: Record | undefined,
): Promise> // return modified args or throw to deny
}
```
server.use(myAuthMiddleware, myAuditMiddleware)
Middleware runs in registration order. Throwing short-circuits the chain and returns an MCP error response without invoking the handler. `meta` exposes `params._meta` so middleware can read authorization context passed by the client.
The GitHub MCP server merged equivalent support in github/github-mcp-server#2026. Happy to submit a draft PR.

Start by locating the existing DENIED_COMMANDS mechanism and the server startup paths across the repository. Trace how tool calls reach handlers and how MCP error responses are returned; the work is done when startup middleware registration, ordered before-call interception, argument modification, metadata access, and short-circuit denial behavior are defined and covered across the relevant servers.

Written by the indexing model from the issue text.