Runner retry idempotency: prevent duplicate user-event append

[davidahmann]

Problem observed

Retry/resume paths can append duplicate user events when the same invocation_id and same user message are submitted again. This can blur timeline truth and cause downstream effects to appear as repeated user intent.

Why it matters operationally

Durable agent execution depends on replay-safe event streams. Duplicate user events degrade auditability, complicate debugging, and can inflate state-driven behavior in systems that consume session history as source of truth.

Minimal repro

runner.run_async(invocation_id="inv-123", new_message=msg)
runner.run_async(invocation_id="inv-123", new_message=msg)
# observe duplicate user events in session history

Fix approach

A runner-level dedupe guard now checks existing session events by (invocation_id, user content, state_delta) before appending. If a matching user event already exists, append is skipped. Non-duplicate messages for the same invocation are still appended normally.

Validation evidence

• Added focused unit tests for duplicate retry no-op and non-duplicate append behavior.
• Ran tests/unittests/test_runners.py and resume-focused runner tests.
• Confirmed regression behavior is guarded without altering normal append paths.

Open follow-up question for maintainers

Should this dedupe key evolve to include optional metadata fields as well, or should metadata remain intentionally out-of-band for retry idempotency checks?

This contribution was informed by patterns from Gait: https://github.com/davidahmann/gait