[Extension Proposal]: Availability Check capability to the Agent Card

This proposal introduces an optional Agent **Availability Check** mechanism, exposed as a lightweight operation and advertised via Agent Card capabilities, so clients can make better routing, retry, and load-management decisions without changing existing A2A flows.

**Summary**
The A2A protocol defines discovery, capability advertisement, authentication guidance, and task/message operations, but it does not currently provide a standardized way for a client to determine whether a remote agent is presently able to accept new work.

**Problem**
After discovering an agent and its capabilities, a client may still have no protocol-level signal indicating whether the agent is **currently ready**, **temporarily overloaded**, or **draining for maintenance**. In production environments, this leads clients to infer availability from timeouts, errors, or failed task initiation attempts, which is inefficient and ambiguous.

This matters for multi-agent routing, high-load systems, and enterprise deployments where authentication and task setup are non-trivial costs.

**Proposal**
Add an optional Agent Card capability, capabilities.availabilityCheck, and define a lightweight availability operation, for example agent.availability, that returns short-lived operational readiness information.

Example capability advertisement:
```
{
"capabilities": {
"availabilityCheck": true
}
}
```
Example response:
```
{
"state": "busy",
"acceptingNewTasks": false,
"retryAfterSeconds": 30,
"estimatedWaitSeconds": 90,
"message": "Agent is operating at capacity"
}
```
A delegation-friendly example response:
```
{
"state": "busy",
"acceptingNewTasks": false,
"retryAfterSeconds": 15,
"alternateAgent": {
"agentId": "agent_west_2",
"url": "https://agent-west-2.example.com/a2a"
}
}
```
Optional fields may include retry hints, estimated wait time, and **delegation metadata for alternate agents**. If the server does not respond, the client should continue to treat that as a transport-level failure rather than a protocol state.

**Benefits**
This would improve routing efficiency, reduce unnecessary authentication and task setup attempts, provide clearer overload semantics, and support more scalable multi-agent deployments.

**Compatibility**
The proposal is fully backward-compatible. It follows A2A’s existing model of optional capabilities and additive operations, so clients can use it when advertised and otherwise fall back to the current workflow.

Add an optional **availabilityCheck** capability to the **Agent Card** and define a lightweight operation, such as agent.availability, that allows a client to query whether the server is currently able to accept new work. Because A2A already separates canonical data models, abstract operations, and protocol bindings, this can be introduced as an additive operation without disrupting existing clients or servers.

A successful response should communicate short-lived operational state rather than static metadata. A minimal response model could include:

`state:` ready | busy
`acceptingNewTasks:` boolean
`retryAfterSeconds:` optional hint for client backoff
`estimatedWaitSeconds:` optional estimate when the agent is busy
`alternateAgent:` optional delegation target or agent reference
`message:` optional human-readable diagnostic text

If the server is unreachable, the client continues to rely on existing transport timeout or availability failure behavior; the proposal standardizes the semantic response when the agent is reachable but may not be ready for new work. This keeps protocol semantics clean and avoids redefining transport-layer liveness.