fix(deps): pin skim to 5.1.0 to unblock Windows picker

[worktrunk-bot]

Problem

CI on main is red on Windows. Every interactive-picker integration test (test_switch_picker_abort_with_escape, test_switch_picker_alt_l_does_not_hscroll, and the rest of switch_picker) fails with:

✗ interactive picker failed: Keyboard progressive enhancement not implemented for the legacy Windows API.

Root cause is the skim 5.1.0 → 5.3.1 bump (#3526), one of three dependabot PRs that merged together at 01:46. skim 5.3.0 added Kitty keyboard protocol support (skim-rs/skim fix: kitty keyboard protocol), which in tui/backend.rs::execute_enter unconditionally runs:

crossterm::execute!(
    stderr(),
    PushKeyboardEnhancementFlags(KeyboardEnhancementFlags::DISAMBIGUATE_ESCAPE_CODES)
)?;

On the legacy Windows console API, crossterm's PushKeyboardEnhancementFlags returns an error, and skim propagates it with ? as fatal rather than degrading. There is no supports_keyboard_enhancement() capability guard, and it is still absent as of skim 5.3.2 (which only added packaging CI). The last green main run was the docs commit 65f02693, before the skim/tokio/taiki-e bumps landed; tokio and taiki-e can't produce a terminal-keyboard failure.

Solution

Pin skim to the last known-green line, =5.1.0, and revert Cargo.lock to match (this restores exactly the pre-bump resolution — frizbee 0.10.0, color-eyre re-added). 5.1.0 predates the Kitty-protocol code entirely, so the picker never touches the Windows-unsupported path.

5.2.0 also predates the regression but changes skim's border defaults ("collapsed borders by default"), which would churn picker snapshots across all platforms — out of scope for a CI unblock — so the pin holds at the 5.1 line rather than <5.3. Lift the pin once skim guards the enhancement behind terminal capability detection.

Testing

• cargo build --bin wt — compiles with skim 5.1.0.
• cargo test --test integration --features shell-integration-tests -- switch_picker::test_switch_picker_abort_with_escape switch_picker::test_switch_picker_alt_l_does_not_hscroll — both pass on Linux.

The failure itself is Windows-only and can't be reproduced in the Linux sandbox, but 5.1.0 was proven green on every platform (including Windows) before the bump, so restoring it returns main to that state. Windows CI on this PR is the confirming signal.

---

Automated fix for failed run

[worktrunk-bot]

The default branch is still red on this — run 29884002936 (commit 89b58e2, the taiki-e/install-action bump) hit the identical switch_picker failure on the Windows coverage job: interactive picker failed: Keyboard progressive enhancement not implemented for the legacy Windows API. Same root cause this PR fixes (skim 5.3.1).

Heads up that #3538 (maintainer-authored) lands the same skim = "=5.1.0" pin, so these two overlap — worth consolidating on one to avoid double review. No new fix needed here.

[max-sixty]

Superseded by #3538, which merged the identical skim = "=5.1.0" pin (Cargo.toml + Cargo.lock) and returned test (windows) to green on main. Closing this as a duplicate.

If you think this was closed in error, let us know and we'll reopen it.

This was written by Claude Code on behalf of Maximilian Roos