Proposal: minimal Ed25519 + RFC 9421 signing extension for A2A messages

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

A2A 1.0 defines several authentication primitives but no per-message signing layer:

- **§4.5 Security Objects** `APIKey`, `HTTPAuth` (incl. Bearer), `OAuth2`, `OpenIdConnect`, `MutualTLS`. All
transport/session-level.
- **§7 Authentication and Authorization** handshake and credential-passing flows building on §4.5.
- **§8.4 Agent Card Signing** signature over the AgentCard *document itself* (canonicalization in §8.4.1, signature
format in §8.4.2, verification in §8.4.3).

what's missing is a primitive that lets a receiver cryptographically verify *this specific request* came from the
claimed agent. Bearer tokens (§4.5.3) delegate trust to a third-party IdP; mTLS (§4.5.6) doesn't survive proxies;
AgentCard signing (§8.4) covers the card, not the messages.

### Describe the solution you'd like

This issue proposes a **minimal, wire-format-only, non-hosted** signing extension to fill that gap:

- **Algorithm:** Ed25519 (per RFC 8410 SPKI).
- **Format:** RFC 9421 HTTP Message Signatures, components `("@method" "@path" "content-digest")`, params `created` +
`nonce` + `keyid`.
- **`keyid`:** a self-resolving HTTPS URL. `GET ` MUST return `{ "address": "...", "public_key": "...PEM..."
}`. No central registry; the agent's own server (or its registry of choice) hosts the resolution.

Why this shape?

This shape responds directly to a concern @abdelsfane raised on #1511:

> "A protocol-level extension should define *interfaces and behaviors*, not route traffic to a particular service."

The `keyid`-as-URL design satisfies that: a verifier needs nothing beyond an HTTPS GET. Anyone can host (their own
domain, GitHub Pages, a managed registry).

### Describe alternatives you've considered

- **#1497 / PR #1496** (@thebenignhacker extension-based, zero-protobuf-change framework) — fully compatible. This proposal can be the wire format inside the extension #1496 introduces.

- **PR #1511** (@The-Nexus-Guard DID-based AIP) complementary. `keyid` URL is a degenerate `did:web` resolver;
bridging is one HTTP fetch.

- **#1786** (@aeoess CTEF v0.3.1-aligned identity claims) operates above the signing layer. The four claim
categories (identity, transport, authority, continuity) can ride on top of the per-message signature this proposal
defines.

- **#1575** (@aeoess agent-passport-system) operates at a higher layer of abstraction, including delegation,
signed receipts, and commerce-preflight gates. This proposal sits beneath those features as the narrower per-message signing primitive they can build on.

### Additional context

- Spec: https://envoys.me/specs/signature/v1 (v1.3.0)
- SDK: [`@envoys/sdk`](https://www.npmjs.com/package/@envoys/sdk) v0.6.4 (MIT) - generic verifier
- A2A adapter: [`@envoys/a2a`](https://www.npmjs.com/package/@envoys/a2a) v0.5.4 (MIT) - framework-agnostic A2A handler
- Source: https://github.com/jschoemaker/Envoys-public

**No protocol-level coupling to a registry:** the verifier resolves whatever URL appears as `keyid` on the wire. The
Envoys SDK's signer defaults to `https://envoys.me` for convenience but accepts any base URL; agents that don't want to use envoys.me can publish their public key at any HTTPS endpoint (own server, static hosting, alternative
registry).

Happy to send a companion PR mirroring #1496's extension-based shape, with the wire format in
`extensions/signature/v1.md`. Want feedback on whether the protocol-level direction is the right shape before code
lands.

### Code of Conduct

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