#810 JUMPER-CORE: concurrent claim/suspend/emit leaves runs in corrupted stuck state (#agentic)

Under concurrency (12 parallel approval-timeout runs), runs get stuck: run.state='sleeping' + task.state='running' + claimed_by=<worker> + available_at='infinity' + no wait row. await_event's suspend (set run+task sleeping, claimed_by null, finite available_at, register wait) is not atomic/consistent vs a concurrent claim or emit_event re-queue -> inconsistent state. Consequences: (1) claim-poll can't recover (available_at=infinity never <= now); (2) no reaper reclaims an EXPIRED claim on a SLEEPING run (reaper likely targets state='running'/'pending'); (3) the wake orphan-reconcile skips task!='sleeping' to avoid busy-looping on unrecoverable runs. Needs: atomic claim/suspend, never available_at=infinity at the await_event level (currently only the raw JumperClient.await_event was clamped - the SQL jumper.await_event still does coalesce(timeout_at,'infinity')), and a reaper for expired-claim sleeping runs. Discovered while root-causing #809. HIGH priority: undermines durability under load.