fix(issue-5): bind the auto-completion decision atomically to its attempt

Two findings from round 2, both reproduced before being accepted.

R2 -- attribution was compared before the terminal write and nothing tied the
two together. A job could complete, be re-dispatched and claimed again in that
window, and evidence from the first attempt then satisfied a status check and
finished the second one. Reproduced with real transitions: committed, with the
registry already on iteration 2.

This corrects my own earlier reasoning, and I want to be plain about it. Last
round I argued that the attempt guard could live entirely in the evidence layer
because that is where attempt identity lives. That holds for comparing evidence
to a dispatch, and it does not hold for atomicity: a precondition can only be
atomic with the commit if the transaction can read it under its own lock. So the
identity now lives in the record.

It is an opaque dispatch token, not the iteration counter. That distinction is
the part of the earlier rebuttal that still stands: iteration already means the
loop round, and comparing a dispatch attempt against it produces a guard that is
vacuous when they agree and wrong when they diverge. A token has no competing
meaning. It is minted when an attempt begins -- claim and redispatch -- and the
gate passes the token it decided against, so any intervening re-dispatch refuses
the commit.

R4 -- the intent identity was being emitted but nothing consumed it. A replayed
notification is re-published with a fresh wire sequence, so the monotonic guard
cannot recognise it; to that guard a retry looks new. The subscriber now
deduplicates on the stable intent identity, leaving the sequence guard as the
rule for ordinary events. Across a restart the disk fallback resolves terminal
status and a duplicate terminal is refused as an idempotent ack, so a replay
after restart cannot double-apply either.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UrDNJkHmm18uu7n7JwV5Qd

.agents/skills/lib_py/delegation/job_subscriber.py

@@ -100,6 +100,17 @@ class _Watcher:
         self.expected = set(expected_job_ids)
         self.tokens = expected_tokens  # job_id -> expected auth_token (or None)
         self.last_seq = dict(expected_seqs)
+        # Intent identities already accepted, per job. A replayed notification is
+        # re-published with a *fresh* wire sequence, so the monotonic sequence
+        # guard below cannot recognise it: to that guard a retry looks like a new
+        # event. The intent identity is what stays stable across a retry, so
+        # deduplication has to happen on that.
+        #
+        # This is per-process state. Across a restart the disk fallback resolves
+        # terminal status from the registry, and a duplicate terminal is refused
+        # by the transition boundary as an idempotent ack, so a replay after
+        # restart cannot double-apply either.
+        self.seen_intents = {}
 
     def on_message(self, _client, _userdata, msg) -> None:
         # --- defensive parsing -------------------------------------------
@@ -129,6 +140,15 @@ class _Watcher:
         if seq is None or not isinstance(seq, int):
             logger.warning("drop event for job %s: missing or invalid seq", jid)
             return
+        intent = (payload.get("data") or {}).get("notification_intent")
+        if isinstance(intent, dict):
+            identity = (intent.get("seq"), intent.get("event"), intent.get("timestamp"))
+            if identity in self.seen_intents.setdefault(jid, set()):
+                logger.info("drop event for job %s: notification intent %s already accepted",
+                            jid, identity)
+                return
+            self.seen_intents[jid].add(identity)
+
         if seq <= self.last_seq.get(jid, 0):
             logger.warning("drop event for job %s: seq %d is not monotonically increasing (last %d)",
                            jid, seq, self.last_seq.get(jid, 0))