[Spec] Define normative AgentCard capability declaration contract for safe agent discovery

## Problem

Agent Cards declare capabilities (e.g., `pause_resume`, `streaming_message`, `push_notifications`), but the specification does not define:

1. **Which capabilities MUST be declared** vs implicitly assumed
2. **Backward-compatibility rules** when new capabilities are introduced
3. **How multi-agent orchestration** validates capability compatibility before delegating tasks
4. **Safe discovery boundaries** — what can agents safely assume about peers without checking?

This ambiguity creates **critical interoperability risks**:

- **Silent capability drift**: Agents add new capabilities without declaring them; orchestration chains break
- **Unsafe discovery**: Orchestrator discovers Agent B without validating it supports capabilities needed for the task; task fails mid-execution
- **Backwards incompatibility**: New agents with new features can silently break clients expecting old behavior

## Evidence

From recent issues and design discussions:
- a2aproject/A2A#1285: "Is supportedInterfaces information that must be declared?" → **unanswered confusion**
- a2aproject/A2A#1286: Request to add `source` field in Messages for multi-agent scenarios (requires capability declaration)
- a2aproject/A2A#1276: Pause/Resume added as capability flag; **how do agents discover this?**
- a2aproject/A2A#1313 (Phase B): Message/Artifact unification deferred; needs **capability versioning** strategy
- No reference implementation or test demonstrating capability negotiation

## Proposed Solution

### 1. Define Capability Tiers

**Tier 1: Implicit** (all compliant agents MUST support without declaration):
- `SendMessage` (single message only, no history)
- `GetTask`
- `ListTasks`
- Basic error handling

**Tier 2: Declared** (optional; MUST be in Agent Card if supported):
- `pause_resume`: bool — agent supports pause/resume operations (task can transition to PAUSED state)
- `streaming_message`: bool — agent can stream Message objects with `partial: true` flag (#1261)
- `push_notifications`: bool — agent supports push notification registration (#1372)
- `context_reuse`: bool — can agents share context ID across separate calls?
- `multi_tenant`: bool — agent runs in multi-tenant mode; check `AgentInterface.tenant`
- `message_history_injection`: bool — agent accepts injected message history in SendMessage (#1373)
- Custom capabilities via Extensions: Extensible schema for vendor-specific capabilities

**Tier 3: Deprecated** (supported but discouraged):
- Direct artifact streaming (superseded by Message streaming in a2aproject/A2A#1313 Phase A)

### 2. Version Negotiation Fields (New in AgentCard)

Add optional version range fields to `AgentCard`:

```protobuf
message AgentCard {
...
// Minimum A2A protocol version this agent supports
string min_protocol_version = 7; // e.g., "0.3.0"
// Maximum A2A protocol version this agent supports
string max_protocol_version = 8; // e.g., "1.2"
}
```

Also add to `AgentInterface` for protocol-binding-specific version negotiation:

```protobuf
message AgentInterface {
...
// Protocol version(s) supported by this interface
repeated string protocol_versions = 4; // e.g., ["1.0", "1.1"]
}
```

### 3. Discovery Safeguards (Normative Pattern)

When discovering an agent (client-side validation):

```python
def safe_discover(agent_card: AgentCard, my_protocol_version: str) -> bool:
# Check version range compatibility
if not version_in_range(my_protocol_version,
agent_card.min_protocol_version,
agent_card.max_protocol_version):
log.warning(f"Agent protocol version {agent_card.min_protocol_version}-{agent_card.max_protocol_version} incompatible with mine {my_protocol_version}")
return False

# Check required capabilities for intended use case
if my_task_requires_streaming and not agent_card.capabilities.get("streaming_message"):
log.warning("Agent does not declare streaming_message capability; streaming will fail")
return False

return True
```

### 4. Multi-Agent Orchestration (Transitive Capability Validation)

When Agent A delegates to Agent B (which may delegate to Agent C):

```
A → B → C

Step 1: A discovers B, validates B.capabilities against task requirements
Step 2: If B delegates to C, B must validate C.capabilities
Step 3: If B's capability = "context_reuse: false", A cannot rely on shared context
```

**Failure mode without validation:**
```
A requires streaming_message
A discovers B (no capability check)
A sends streaming message to B
B fails because it doesn't support streaming
→ Silent failure mid-orchestration
```

**With validation:**
```
A requires streaming_message
A discovers B
A checks: B.capabilities.streaming_message == false
A refuses to delegate to B, tries next agent
→ Deterministic, predictable behavior
```

### 5. Capability Stability Guarantee

Once a capability is declared in the specification, it has stability guarantees:

- **Cannot be removed** (only deprecated)
- **Can only be extended** (new fields added, not removed)
- **Deprecation period**: 2 major versions before removal (if ever)
- **Example**: `pause_resume` introduced in v1.0 → cannot be removed in v1.x, marked deprecated in v2.0, removed in v3.0

This ensures orchestration chains don't break on minor version updates.

## Acceptance Criteria

- [ ] Add new "Capability Declaration & Discovery" section to `docs/specification.md` with subsections:
- Capability tiers (Tier 1/2/3)
- Declaration requirements
- Version negotiation
- Safe discovery pattern (pseudocode)
- Multi-agent orchestration rules
- [ ] Update `a2a.proto` AgentCard and AgentInterface with:
- `min_protocol_version`, `max_protocol_version` fields (strings, optional)
- `protocol_versions` array in AgentInterface (new field, optional)
- Comment blocks explaining each new field
- [ ] Create conformance test case `tests/conformance/capability-discovery.json`:
- Golden trace: Agent A discovers B, validates capabilities, delegates task
- Invariant: If B doesn't declare `streaming_message`, no streamed messages sent
- Invariant: Version mismatch detected before delegation
- [ ] Document in `CONTRIBUTING.md` / SDK development guide:
- "How to declare capabilities in your agent"
- "How to validate discovered agent capabilities"
- Checklist for new capability additions
- [ ] Update existing issues:
- a2aproject/A2A#1276 (pause_resume): Add acceptance criterion "Agent declares `pause_resume: true` in capabilities"
- a2aproject/A2A#1286 (source field): Add acceptance criterion "Agent declares support for multi-agent attribution"
- a2aproject/A2A#1313 (Phase A/B): Cross-reference this for version/capability negotiation strategy

## Why This Matters

| Without This | With This |
|-----------|-----------|
| ❌ Silent capability drift | ✅ Explicit declarations; versioning prevents drift |
| ❌ Multi-agent chains break mid-task | ✅ Capability validation before delegation |
| ❌ New features break old clients | ✅ Version negotiation + deprecation path |
| ❌ SDKs implement discovery differently | ✅ Normative pattern ensures consistency |
| ❌ "Free discovery is dangerous" (per lens) | ✅ Bounded discovery: validated compatibility |

## Related Issues & Linked Work

- **Streaming**: a2aproject/A2A#1261 (Message streaming) — new capability `streaming_message`
- **Unification**: a2aproject/A2A#1313 (Message/Artifact) — Phase A/B roadmap references versioning
- **Agent Features**: a2aproject/A2A#1276 (pause_resume), a2aproject/A2A#1286 (source field) — examples of declared capabilities
- **Multi-tenant**: a2aproject/A2A#1271 (tenant field), a2aproject/A2A#1273 (multi-tenancy) — capability declaration for tenancy
- **Orchestration**: a2aproject/A2A#1317 (context reuse) — needs capability negotiation

## Additional Context

This proposal addresses the "free discovery is dangerous" lens from the A2A architecture review:

> *Discovery of new agents/capabilities can silently break existing agents (capability drift / compatibility breakage). Identify where A2A discovery/selection could produce unstable or incompatible interactions. Propose compatibility constraints and safety gates.*

**This issue proposes those safety gates**: explicit capability declaration, version negotiation, and safe discovery patterns.

The work involves updating the specification in docs/specification.md and the protocol buffer definitions in a2a.proto. Start by reading the existing spec and proto files to understand the current AgentCard structure. The acceptance criteria list specific files to modify and a test to create. 'Done' means the spec section is written, the proto fields are added, and a conformance test case is provided.

Vom Indexierungsmodell aus dem Issue-Text verfasst.