feat: restore checkpoint after any AI response turn

[Basit-Balogun10]

Note: This PR is stacked on #2321. The diff shows +2k lines because GitHub uses main as the base - cross-fork branches can't be set as PR bases (tried using Graphite to track the stack too, same limitation). The actual changes in this PR are a few commits on top of #2321. Please review with that context, or we wait for #2321 to be merged first.

Problem

After an AI turn completes, there's no way to roll back to the git state captured at the end of that turn. If the agent goes down a wrong path you have to manually reset the branch or throw away work — there's no checkpoint-based undo.

Tracked in #724 / #2328.

Changes

Core restore flow

• New checkpoint tRPC router (routers/checkpoint.ts) with a restore procedure that:
  1. Runs RevertCheckpointSaga to reset the worktree to the saved git state
  2. Truncates the session .jsonl to the restore point so the session replays correctly
  3. Collects any orphaned checkpoint refs from the discarded lines and deletes them — no accumulation of stale refs from abandoned future turns
• getSessionInfo(taskRunId) added to AgentService to expose { sessionId, repoPath } without leaking internal types

Per-turn restore button

• buildConversationItems tracks lastCheckpointId per turn — set when a _posthog/git_checkpoint notification is seen, cleared on each new turn start
• Each user message shows a restore button (visible on hover): enabled when that turn has a checkpoint, disabled with an explanatory tooltip when it doesn't, and disabled with a "not available for cloud tasks" tooltip for cloud sessions

Restore confirmation

• RestoreCheckpointDialog — confirmation dialog with an amber warning before the restore runs, so accidental clicks don't immediately drop work
• useRestoreCheckpoint hook wires the full flow: opens the confirmation dialog → calls the tRPC mutation → truncates the in-memory events via sessionStoreSetters.truncateEventsToCheckpoint → shows a success/error toast

How did you test this?

• Full pnpm typecheck passes across all packages (exit 0); biome clean via the pre-commit hook
• Automated tests (vitest) for the restore path — see the "Hardening + tests" section below for the breakdown. All green except 3 pre-existing, Windows-only getSessionJsonlPath path-separator assertions (they assert forward-slash paths; path.join emits backslashes on Windows) which pass on Linux CI and are unrelated to this change
• Manual end-to-end (local Codex session): restored to a prior turn, reloaded the page — no duplicated history — and confirmed the resumed agent's memory stops at the checkpoint (asked it to recall later turns; it had none)
• Verified the cloud guard: restore is blocked with a message for cloud sessions, and the per-turn button / timeline reflect checkpoint availability

---

Scope: local-only (cloud is intentionally gated)

Checkpoint restore is available for local tasks only. This is by design, not an oversight.

Why checkpoints only exist for local turns. Checkpoints are git commits captured against the local worktree by the local agent after each turn (captureLocalCheckpoint → CaptureCheckpointSaga). A cloud task runs on remote infrastructure with no local agent and no local turn-completion hook, so it emits no _posthog/git_checkpoint events. The per-turn restore button is therefore rendered disabled with a "not available for cloud tasks" tooltip for cloud sessions (and disabled with a "no checkpoint for this turn" tooltip for any local turn without one).

Why restore cannot run for a cloud session. Restore performs three local-machine operations: (1) RevertCheckpointSaga rewinds files in the local worktree, (2) cancelSession SIGTERMs and reconnects the local agent subprocess, (3) truncateCodexRollout rewrites the on-disk rollout. None apply to a remote run whose agent and worktree live server-side. The S3 truncate_log call is the only cloud-capable piece, and on its own it would truncate the displayed history while the remote agent kept full memory and files stayed put — worse than a no-op. useRestoreCheckpoint therefore blocks isCloud sessions with a clear message before any destructive revert.

Handoff behavior. For a task that spans local and cloud (either direction), only turns that executed locally have checkpoints. Turns that ran in the cloud show no restore icon; local turns remain restorable. If a task with local checkpoints is currently running in the cloud, the click-time guard prevents a partial restore.

What full cloud support would take (future, out of scope). A backend feature, not a client flag: (1) server-side per-turn checkpoint capture that writes the checkpoint_id → prompt_id mapping into the run log so the client timeline can render restore points, (2) a server-side restore endpoint that reverts the remote worktree + truncates the remote agent memory + resumes atomically, (3) client rewiring to call that endpoint for cloud sessions, and (4) a product decision for runs with external side effects already pushed (commits/PRs). This touches the cloud runner + API and is tracked separately.

Hardening + tests added since initial review

• Duplication fix (Codex): suppressReplay gate drops the rollout re-stream during loadSession so resumed sessions do not re-persist history to logs.ndjson/S3.
• Memory truncation: on-disk codex rollout + local logs are trimmed to the checkpoint boundary; a Windows file-lock race on the rollout write is handled with bounded retry.
• Concurrency: overlapping restores for the same session are rejected with an in-flight lock (prevents two restores racing to truncate at different offsets).
• Failure surfacing: the restore mutation returns truncationFailed; the renderer warns when agent memory may extend past the checkpoint instead of failing silently.
• Edge cases: "Current" badge on the most-recent checkpoint (no-op restore), a note when restoring will stop an in-progress response, and the cloud-session rejection message above.
• Automated tests: rollout truncation + lock retry, codex suppressReplay (client + agent wiring), local-log prompt-boundary truncation, checkpoint-router concurrency lock, and Claude JSONL hydration parity (force-refetch, no replay).