[Reliability] Make mention invocation claims recoverable after pre-forward failure #893

Problem

The mention router uploads an immutable 30-day exact-key artifact claim before forwarding. This gives useful at-most-once behavior, but if the claim succeeds and forwarding fails, the original request is dead-lettered for the retention period. Recovery requires a new trusted source comment and creates a different key; the claim does not distinguish completed authoritative work from a pre-forward failure.

Required contract

Preserve replay safety while making claim state and recovery explicit. A failed acknowledgement remains non-authoritative, and recovery must not create duplicate review/mutation authority.

Acceptance criteria

• Model claim states such as reserved, forwarded, accepted, completed, failed-before-forward, and expired with exact repository/PR/head/base/agent/comment identity.
• Define owner, TTL, retry eligibility, fencing/idempotency token, and safe takeover semantics.
• An unchanged completed request is never forwarded twice.
• A pre-forward failure can be retried or requeued without waiting 30 days or requiring ambiguous manual cleanup.
• Tests cover artifact visibility delay, upload collision, forward timeout, crash after reserve, crash after forward, duplicate sweep, new comment, and head/base movement.
• Operator diagnostics state whether a new comment is required and why.
• Protected-main acceptance exercises failure and recovery on a real comment invocation.

Dependencies

End-to-end dispatch snapshot binding and review-only semantics remain tracked in #840.