[Feat]: Swarm Extension Family proposal — posture/blackboard/routing/presence extensions for A2A v1.0

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

This is a formal **extension proposal** under the [A2A Extension & Binding Governance](https://a2a-protocol.org/latest/topics/extension-and-binding-governance/) process (Proposal Phase).

The A2A v1.0 core protocol is a task/reply protocol: agents discover each other via Agent Cards, exchange messages, and track long-running tasks. It has no representation for four operational concerns that any persistent multi-agent deployment hits:

1. **Agent lifecycle state (posture)** — agents are assumed always available. Real swarms sleep idle agents to save tokens/energy and need an explicit wake path.
2. **Shared knowledge with decay** — A2A exchanges messages but has no cross-agent memory with a freshness/time dimension.
3. **Tag-based routing** — fan-out requires enumerating peers and sending individually; there is no interest-group broadcast that decouples sender from recipient set.
4. **Presence/liveness** — Agent Cards describe capability, not liveness; operational routing needs a heartbeat + last_seen.

### Describe the solution you'd like

A **Swarm Extension Family**: four optional, versioned extension URIs that give any A2A-compliant agent access to these operational primitives:

| URI | Purpose | Custom JSON-RPC methods |
|---|---|---|
| `https://hermes.nousresearch.com/extensions/swarm/v1/posture` | sleep/awake posture control + wake command | `swarm/posture` |
| `https://hermes.nousresearch.com/extensions/swarm/v1/blackboard` | shared decaying-pheromone knowledge | `swarm/blackboard/post`, `swarm/blackboard/query` |
| `https://hermes.nousresearch.com/extensions/swarm/v1/routing` | tag-based broadcast (ask/signal) | — (core `SendMessage` + extension metadata) |
| `https://hermes.nousresearch.com/extensions/swarm/v1/presence` | heartbeat + online state | `swarm/presence/ping` |

Key design points:

- **All extensions are `required: false`** — a non-extension client sees a fully conformant A2A agent; the extension list is additive metadata in the Agent Card.
- **Extension-only operations short-circuit at the daemon: zero LLM turns** for posture/blackboard/routing/presence — they are typed, idempotent operations on agent state, not model calls.
- **Versioned URIs** — breaking changes get a new URI (spec §4.6.3).
- **Transport:** A2A v1.0 HTTP+JSON binding; JSON-RPC 2.0 custom methods declared in the Agent Card per §12.
- **Decay semantics:** blackboard findings carry a pheromone strength (0–1) with ~24h half-life, so stale knowledge ages out organically.

### Describe alternatives you've considered

- **Core protocol change** — rejected: these are cross-cutting operational concerns common to many deployments, exactly the "protocol enhancement" category the extensions mechanism exists for (§4.6); core changes would break backward compatibility.
- **Custom protocol binding (CPB)** — rejected: the semantics are not transport-specific; they layer on the standard HTTP+JSON binding.
- **Vendor-private extension namespace** — that's where this proposal starts (the reference implementation uses `https://hermes.nousresearch.com/extensions/swarm/v1`), but the governance path to an `experimental-ext-swarm-*` repo and eventual official status is the ask here.

### Additional context

**Complete formal spec (v1 draft):** https://gist.github.com/RGerrish/b4cbf13e4de4680d402952557cbd6c84

**Reference implementation (production, Apache-2.0, 152 tests):** hermes-swarm v0.10.0 — `a2a_bridge.py` (655 LOC, stdlib-only) + `a2a_client.py` (351 LOC); Agent Card at `/.well-known/agent-card.json`. Runs today as a multi-host mesh (macOS + Windows nodes over Tailscale); all four extensions verified live over the wire. Beyond the four extensions, the implementation carries an enforcement progression that shows the family is production-grade: v0.4 delegation receipts (tracked, acked, governor-escalated) -> v0.5 delegation doctrine (domain->owner routing directives) -> v0.6 turn accounting (per-agent work-turn counts + governor balance watchdog) -> v0.7 domain guard (pre_tool_call hard-block of heavy tools for
hard-mode domains) -> v0.8 swarm auto-recovery (stale-registration watchdog
keeps the mesh alive across daemon restarts) -> v0.8.1 inbox-check prompt fix
(kills the `swarm` CLI hallucination that made local models go deaf) -> v0.10.0
receipt truth (two-phase completion: a receipt only reaches `completed` after
deterministic side-effect verification - file/flag/git-commit/blackboard/env
probes or an independent reviewer attestation, never LLM self-report;
`last_activity_at` liveness + governor activity-based escalation)

**What we're asking:**
1. Community feedback on the extension shapes (naming, param semantics, decay model).
2. An A2A Maintainer sponsor to create an `experimental-ext-swarm-*` repository under `a2aproject` so the family can iterate toward official status and, eventually, be considered for core protocol promotion.

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

Review the formal spec draft linked in the issue to understand the four proposed extensions: posture, blackboard, routing, and presence. Examine the reference implementation files a2a_bridge.py and a2a_client.py for the current extension mechanics. The goal is to gather community feedback and seek a maintainer sponsor to create an experimental repository under a2aproject.

Scritto dal modello di indicizzazione a partire dal testo della issue.