[bug] in_progress quests have no stale-timeout recovery; crashed-agent claims held indefinitely

[kunallanjewar]

Summary

When an agent accepts a quest, quest_accept atomically claims it via CAS UPDATE (see internal/quest/accept.go:90) and the quest stays in_progress until explicit quest_clear or quest_forfeit. If the agent crashes, disconnects, or otherwise terminates without releasing the quest, there is no heartbeat or timeout mechanism to recover the claim. The quest is held indefinitely by a dead owner.

The atomic re-claim rejection (returning AlreadyClaimedError) works correctly for the concurrent-accept race, but it also blocks legitimate recovery: a new agent cannot pick up a stuck quest, and there is no operator-side surface for diagnosing how long a quest has been in flight or which owner held it last.

Affected files

• internal/quest/accept.go
• internal/quest/list.go (status filters / introspection)
• internal/quest/forfeit.go (manual release path)

Acceptance

• A configurable stale threshold (e.g. claimed_at > N minutes ago) is surfaced via quest list or a new introspection verb.
• Stale claims can be auto-released, OR explicitly reclaimed via an override flag (e.g. --force) so the choice stays with the operator.
• The current atomic re-claim contract for non-stale claims is preserved.
• Output surfaces claimed_at and claimed_by so an operator can decide before overriding.

[hipvlady]

The four invariants this needs are heartbeat (so liveness is observable from outside the claimant), bounded lease TTL (so the absence of heartbeats is a finite signal, not an indefinite wait), max-hold ceiling (so even healthy long-running claimants rotate before they trap the whole queue), and reclaim that preserves single-writer at the moment of force-release (so the reclaim itself doesn't violate the invariant the original CAS was protecting). The composition is load-bearing: max-hold > lease TTL or the protocol is incoherent under pathological clock skew.

Mapping to Guild's task_status row: claimed_at is the lease start, a periodic claimed_heartbeat_at write from the holder is the liveness signal, a sweep job evaluates (now - max(claimed_heartbeat_at, claimed_at)) > lease_ttl to mark claims reclaim-eligible. The reclaim itself is a second CAS — UPDATE task_status SET status='next', claimed_by=NULL WHERE task_id=? AND claimed_at=? — keyed on the original lease start so a holder that resumes after partition (network blip, MCP host hiccup) loses its claim cleanly instead of racing the reclaim.

We landed this on the artifact-coherence side as Candidate C in v0.6.0 with a TLA+ model covering single-writer preservation under reclaim. Same shape as what Issue #89 needs; happy to share the spec if useful — formal/tla/CrashRecovery.tla in github.com/hipvlady/agent-coherence.