perf(picker): refresh stale Log preview cache in background after disk hit

[max-sixty]

Summary

The Log preview's cached raw_log bakes in git log --format=%C(auto)%d ref decorations at write time. The cache key is (branch_head_sha, w, h), so another ref starting or stopping pointing at the cached SHA — most commonly a squash-merge landing main at the cached commit — leaves the decoration text stale even though the key is still valid.

Approach

On every disk-cache hit, enqueue a background refresh task on a dedicated picker-preview-refresh thread. The thread drains an mpsc channel serially, calling compute_log_raw_and_stats and overwriting both the disk file and the in-memory PreviewCache DashMap entry. Skim re-invokes the preview callback on every item-change, so navigating row A → B → A within a session shows the refreshed preview on return; a fresh wt switch always reads the disk-refreshed content.

The refresh thread runs separately from the rayon precompute pool so foreground first-paint work never competes with refreshes for worker slots. wait_for_idle covers refresh tasks via the existing PendingGuard pattern: producer increments pending before sending, consumer decrements via guard drop after running.

Trade-offs

• No mtime throttle. Every disk hit triggers a refresh, including hits where the recomputed output would be byte-identical (the common case on stable repos). The dominant cost — the git subprocess — is paid either way; a byte-compare would only save the disk write and DashMap insert. Bounded by serial drain on a single thread.
• User staring at the same row the entire session sees stale decorations — skim has no push-refresh API. Documented at items.rs:219-223. The "comes back to reselect" path is the supported case.

Tests

• log_disk_hit_triggers_background_refresh — seeds disk cache with a stale entry containing a marker; asserts both caches no longer hold the marker after spawn_preview + wait_for_idle.
• non_log_modes_do_not_trigger_log_refresh — seeds disk Log cache, spawns BranchDiff, asserts disk Log cache untouched.

🤖 Generated with Claude Code

[worktrunk-bot]

CI surfaced two issues after my approval — withdrawing the approval per the project's codecov-failure policy.

codecov/patch (3 uncovered lines):

• src/commands/picker/preview_orchestrator.rs:135-139 — channel-send-error rollback. Reachable only if the refresh thread has exited while the orchestrator is still alive, which (given catch_unwind around the task body) requires a panic in the recv-loop setup itself. Defensive but essentially unreachable in practice.
• src/commands/picker/items.rs:271 — PreviewMode::Log => Self::compute_log_preview(repo, item, width, height).0, in compute_preview. The new orchestrator code special-cases PreviewMode::Log to bypass compute_and_page_preview entirely, so this arm is no longer reachable from the only call site (compute_and_page_preview -> compute_preview). Dead after this PR.
• src/commands/picker/items.rs:552 — return (String::new(), false); on git log failure inside compute_log_preview_inner. Reachable in the refresh path: when the disk read succeeded earlier (so the producer enqueued a refresh) but the force_recompute re-run of git log fails. The refresh thread then cache.insert(..., "") and replaces a valid in-memory entry (the rendered disk-cache content) with an empty string, so a return-visit to that row shows an empty preview. Inline suggestion below filters that case.

test (macos) — test_alias_approval_decline panicked with Os { code: 32, kind: BrokenPipe } at tests/integration_tests/step_alias.rs:569. Unrelated to this PR (no overlap with picker code) — looks like a transient PTY/pipe flake. Safe to rerun.

codecov/patch failed — 3 uncovered lines in changed code, see follow-up review for analysis