[Feat]: Standardize cascading cancellation for chained task delegation

### Is your feature request related to a problem? Please describe.

When an orchestrator agent delegates tasks in a chain (A → B → C), cancelling
the root task (Task1 on A) does not propagate to downstream tasks (Task2 on B,
Task3 on C). The current Cancel Task operation (Section 3.1.5) only cancels a
single task on a single server.

As a result, downstream agents continue running after the root is cancelled,
consuming compute resources and producing results that are ultimately discarded
("returned to thin air"). Every orchestrator agent implementation must
independently reinvent cascading cancellation logic, including:
- tracking parent→child taskId mappings across agents
- propagating cancel calls down the chain
- handling partial failures and race conditions
- implementing timeout-based fallbacks

This is a recurring burden for anyone building orchestration on top of A2A,
and inconsistent implementations risk resource waste and unpredictable
lifecycle behavior across the agent ecosystem.

### Describe the solution you'd like

I'd like to see a standardized mechanism for cascading cancellation, ideally
as an optional Extension rather than a core protocol change, to keep the core
simple while solving the real-world orchestration problem.

Proposed approach — a Cancellation Propagation Extension:

1. Add an optional parent-task reference in Message metadata (e.g.,
"parent-task-id" and "parent-context-id") so downstream agents are aware
they were delegated as part of a parent task.

2. Define an Extension URI (e.g.,
https://a2a-protocol.org/extensions/cancellation-propagation/v1) that
agents can declare in their Agent Card.

3. When a parent task is cancelled, the cancelling agent (or the server)
can issue Cancel Task calls to downstream tasks whose parent-task-id
matches, propagating cancellation through the chain.

4. Agents that do not support this Extension continue to behave as today
(no cascading), preserving backward compatibility.

This would complement the existing Traceability Extension and align with
A2A's design philosophy of keeping the core protocol stable while layering
advanced orchestration capabilities via Extensions.

At minimum, even without a full Extension, I'd appreciate a non-normative
guidance note in the specification recommending that orchestrator agents
implement cascading cancellation and timeout-based fallbacks, so that
implementers are aware of this responsibility.

Note: English is not my first language, so I apologize for using an LLM to translate my thoughts into English.

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct