fix: a unique message id, and a peer conversation that survives

Two bugs in the peer call, both found in review.

message_id was context_id + peer name, so every call in a conversation carried
the same id. A2A wants one id per message; a peer treating the second call as a
replay of the first would have looked like a stale answer rather than a bug.

The peer's context_id was derived from hash(subject_token), which was wrong
twice over. hash() on a str is salted per process, so a restart changed the key
— the reported bug. And a fresh token is minted every turn, so the key changed
every turn anyway, which is worse: the peer started a new thread on each call
and lost anything it had parked, the opposite of what the key exists for. It is
now the conversation id, which is what "one conversation per peer" meant.

Not changed: output_type as a list, also raised in review. OutputSpec is
declared as an item OR a Sequence of them, so a list is the API's own form and
not a union written badly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/catalogue_agent/peers.py

@@ -19,6 +19,7 @@ the realm.
 from __future__ import annotations
 
 import logging
+import uuid
 from dataclasses import dataclass
 
 import httpx
@@ -87,7 +88,12 @@ async def ask_peer(
         try:
             request = a2a_types.SendMessageRequest(
                 message=a2a_types.Message(
-                    message_id=f"{context_id}-{peer.name}",
+                    # Unique per message, not per conversation. Reusing one id
+                    # across the turns of a conversation is a protocol error, and
+                    # the failure it invites — a peer treating the second call as
+                    # a replay of the first — would look like a stale answer
+                    # rather than a bug.
+                    message_id=f"{context_id}-{peer.name}-{uuid.uuid4().hex[:8]}",
                     context_id=context_id,
                     role=a2a_types.Role.ROLE_USER,
                     parts=[a2a_types.Part(text=question)],