Rewind audit receipts for tamper-evident session history changes

[davidahmann]

Problem observed

Runner.rewind_async correctly restores state and artifacts, but the rewind event lacked a structured audit receipt proving what boundary was targeted and what history summaries changed. In audits, this made rewind intent and integrity harder to verify because operators had to reconstruct context from surrounding events rather than reading a deterministic receipt attached to the rewind action itself.

Why it matters operationally

Rewind is a high-impact control operation: it changes visible history and influences subsequent model/tool execution context. For incident review and compliance workflows, teams need tamper-evident evidence that captures the rewind boundary and reproducible before/after summaries. Without that, trust in replay analysis depends on indirect logs and manual interpretation, which is slower and less reliable under pressure.

Minimal repro

# create session with multiple invocations
# call Runner.rewind_async(..., rewind_before_invocation_id="invocation2")
# inspect appended rewind event actions metadata
# verify before/after summary hashes remain stable on repeat computation

Fix approach

The change adds a new structured RewindAuditReceipt action payload and populates it directly in Runner.rewind_async. Receipt fields include rewind target, boundary-after invocation, event counts before/after rewind filtering, and deterministic SHA-256 hashes for both history summaries plus the receipt payload itself. Hashing uses canonical JSON serialization (sorted keys, stable separators) to keep outputs reproducible for identical histories.

Validation evidence

• uv run pytest tests/unittests/runners/test_runner_rewind.py tests/unittests/test_runners.py::test_rewind_auto_create_session_on_missing_session
• Added assertions for receipt contents on rewind events
• Added deterministic hash stability test for repeated receipt generation on identical history

Open follow-up question for maintainers

Do you want the receipt hash algorithm/field contract documented as externally stable for downstream auditors, or kept as an internal contract that can evolve with migration notes?

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