Add 'limitations' field to AgentCard

## Summary

Proposal to add an optional `limitations` field to the `AgentCard` message in the A2A specification.

## Motivation

Currently, the `AgentCard` describes what an agent **can** do (via `description`, `skills`, `capabilities`), but there is no structured way to express what an agent **cannot** do or where it may underperform.

Exposing limitations is important for:
- **Agent-to-agent orchestration**: A calling agent can make better routing decisions if it knows the limitations of downstream agents (e.g., language support, file size limits, domain restrictions).
- **User trust & transparency**: Users can set appropriate expectations before interacting with an agent.
- **Safety & compliance**: Explicitly declaring limitations helps prevent misuse in unsupported scenarios.

## Proposed Change

Add a `repeated string limitations` field to the `AgentCard` message in `specification/a2a.proto`:

```protobuf
// Optional. A human-readable description of the agent's limitations,
// helping users and other agents understand what the agent cannot do
// or where it may underperform.
// Example: ["Does not support languages other than English",
// "Cannot process images larger than 10MB"]
repeated string limitations = 15;
```

This field is optional (empty list by default) and fully backward-compatible.

## Examples

```json
{
"name": "Recipe Agent",
"description": "Agent that helps users with recipes and cooking.",
"limitations": [
"Does not support languages other than English",
"Cannot process images larger than 10MB",
"Not suitable for professional nutritional advice"
]
}
```

The change is in specification/a2a.proto, specifically the AgentCard message. Look at the existing fields to understand the structure. Add the repeated string limitations field at the suggested position (field number 15). Ensure the change is backward compatible. Check if there are any tests for the protobuf definitions to run.

Vom Indexierungsmodell aus dem Issue-Text verfasst.