[Feat]: Optional context-binding profile for delegated authority

## TL;DR

Should A2A define an optional profile for binding delegated authority to a specific A2A context?
A valid grant can still be replayed or relayed into the wrong A2A task, session, or target.
This would sit above existing A2A authentication. It is not a new authentication mechanism.

Related: #153 discusses the confused-deputy problem. This issue focuses on binding valid delegation to a live A2A context.

## Problem
Delegated agent flows often need one extra check:

Is this delegation valid for this acting agent, this A2A context, this target, this scope, and this validity period?

Peer-provided metadata should not be authoritative by itself.

The goal is to define what needs to be bound and verified, not a new token format.

## Threats this can be to reduce

- replay of an old delegation into a new task
- relay or diversion across A2A contexts
- confused-deputy behavior from overbroad delegation

## Question

Should A2A define a small optional profile for this kind of task/session-bound delegation context?
Or should this remain entirely application-specific policy?

Review issue #153 for context on the confused-deputy problem. Examine the A2A protocol specification to understand current authentication and delegation mechanisms. The task is to design an optional profile, so start by identifying existing A2A context definitions (task, session, target) and how they are currently managed.

Vom Indexierungsmodell aus dem Issue-Text verfasst.