Support named aliases for multiple AKS target resource IDs

## Problem

`--default-aks-resource-id` / `AZURE_AKS_RESOURCE_ID` removes the need to send `aks_resource_id` for one cluster, but AKS MCP operators commonly need to target several clusters. With the current API, callers must supply a long Azure resource ID on every cross-cluster tool call.

This is error-prone, obscures the intended target in prompts, and makes browser-based MCP clients harder to use.

## Proposal

Add server-side named AKS target aliases that resolve to allowlisted managed-cluster resource IDs.

Example configuration:

```yaml
aksTargets:
development: /subscriptions/.../resourceGroups/.../providers/Microsoft.ContainerService/managedClusters/d-aks
test: /subscriptions/.../resourceGroups/.../providers/Microsoft.ContainerService/managedClusters/t-aks
production: /subscriptions/.../resourceGroups/.../providers/Microsoft.ContainerService/managedClusters/p-aks
```

Expose a `target` / `aks_target` parameter on AKS tools such as `call_kubectl`. It should accept an alias rather than a raw resource ID. An optional configured default alias should preserve the current no-parameter workflow.

## Desired behavior

- Support multiple aliases in server configuration.
- Resolve aliases only on the server; do not expose or require raw resource IDs in normal tool calls.
- Reject unknown aliases before calling Azure.
- Keep explicit `aks_resource_id` support for backward compatibility, or document a migration path.
- Make the tool schema describe the configured aliases so MCP clients can select them reliably.
- Continue to enforce the caller's Azure RBAC and Kubernetes authorization through the existing OBO/RunCommand flow; an alias must be an allowlist, not a permission bypass.

## Motivation

A single remote AKS MCP server can serve several AKS clusters. Named, operator-managed targets would let a user request a command against `production` or `test` without copying a subscription/resource-group/cluster ID into every call.

## Related work

PR #370 introduced the single `--default-aks-resource-id` option. This proposal extends that usability model from one default target to multiple explicit, server-managed targets.

Inspect the configuration handling for --default-aks-resource-id, the call_kubectl tool schema, and the existing OBO/RunCommand path; PR #370 is the closest reference. Define how aliases, defaults, unknown targets, and backward-compatible resource IDs behave, then verify that aliases resolve only to configured targets while existing authorization remains enforced.

Written by the indexing model from the issue text.