[Epic] Auth scheme declaration & credential discovery in AgentCard

## Auth scheme declaration & credential discovery in AgentCard

### Problem

When an A2A server requires OAuth, a client cannot determine *from the Agent Card alone* how to obtain a usable token — today it needs out-of-band knowledge (client registration, which grant, which AS). Assertion-based grants (RFC 7521/7523) are not modeled in the declared flows, and the normative "servers MUST reject invalid/missing credentials" language leaves the SDK-compliance boundary unclear.

### Consolidated issues

- [ ] #830 — OAuth 2.1-compliant authorization for A2A (align with MCP) *(anchor)*
- [ ] #1795 — Support OAuth RFC 7521 assertion-based authorization grants
- [ ] #1770 — Why is JWT assertion (RFC 7523) not one of the declared OAuth flows?
- [ ] #1745 — When OAuth is enabled, how does the client know how to generate the token? *(discovery gap)*
- [ ] #1454 — What does the authentication requirement mean in practice for SDK compliance?

### Acceptance criteria

- The Agent Card's declared security schemes are sufficient for a client to drive token acquisition without out-of-band knowledge (or the required out-of-band steps are explicitly documented).
- Assertion-based grants (RFC 7521/7523) are representable in the declared flows.
- Alignment with MCP's OAuth 2.1 direction is stated.
- The boundary between "protocol-compliant SDK" and "application-specific auth" is clarified (#1454).
- Docs include an end-to-end client token-acquisition walkthrough.