[Feat]: Actor-chain extension: a standard payload shape for on-behalf-of delegation

## Is your feature request related to a problem?

A2A v1.0 carries no principal in the payload. Authentication is out-of-band (`SecurityScheme` declarations plus transport mechanisms), and neither `Message`, `Task`, nor the agent card has a field for the human or upstream agent a request is made on behalf of. `tenant` is routing-only, and `metadata` is untyped, so every implementation that needs delegation context invents a private schema there.

The gap shows up as soon as agents delegate to agents. If agent C receives work from agent B, which received it from agent A acting for user U, C sees only B's transport credentials; the chain A→B→C-for-U exists nowhere on the wire. That loses attribution ("which human caused this side effect?"), makes audit reconstruction a cross-hop log-join, and feeds the confused-deputy problem already described in #153. #1937 proposes binding an already-valid delegation to a task/session/target/scope. This request is the complementary half: a standard shape for *carrying* the chain that a binding profile would bind.

## Describe the solution you'd like

An optional A2A extension (using the v1.0 extension mechanism, i.e. an `AgentExtension` entry in `capabilities.extensions[]`) that reserves one metadata member, `actorChain`, on `Message.metadata`, echoed on `Task.metadata`:

```json
{
"actorChain": {
"origin": { "sub": "user:alice@example.com" },
"actors": [
{ "sub": "agent:coordinator", "scopes": ["repo:read", "ci:trigger"] },
{ "sub": "agent:rebase-worker", "scopes": ["repo:read"] }
]
}
}
```

- The shape deliberately mirrors RFC 8693 (`act` claims, optional `may_act`) rather than inventing a delegation vocabulary. The ID-JAG and WIMSE drafts under active development in the OAuth working group build agent delegation on the same primitives, so an A2A chain can round-trip into token-level mechanisms as those ratify.
- Each hop can carry the scopes it held, so authority attenuation is visible in the audit record.
- **Audit, not authorization.** The chain is attribution history. It must not be used to grant access; authorization stays with the credentials the callee actually validated. A payload field any caller can write must never function as a credential, and the extension text should say so normatively.

Peers that don't declare the extension ignore the member (metadata is already tolerate-by-default). Peers that do declare it append their own hop when delegating onward.

## Describe alternatives you've considered

- **Keep it in private metadata** (status quo): works per-deployment, interoperates with nothing.
- **Core schema field instead of an extension**: cleaner long-term, but delegation semantics are still moving in the OAuth WG; an extension can track that work without holding core hostage.
- **Token-only (no payload representation)**: pushes every A2A implementation to parse provider-specific tokens for display/audit; a payload-level chain keeps audit rendering uniform even when the token format varies.

## Additional context

There's a running implementation of this shape (RFC 8693-style chain validated on ingest, hop appended per delegation, carried in `Message`/`Task` metadata) that we'd be glad to align with whatever shape maintainers prefer. If an extension proposal with a fuller spec draft would be more useful than this issue, happy to write that up.

*Disclosure: drafted with AI assistance and reviewed before posting; the design and implementation experience behind it are human-maintained.*