build(deps): hold skim at 5.1.0 — 5.3.1 breaks the picker on legacy Windows

[max-sixty]

Problem

skim 5.3.1 breaks the picker on the legacy Windows console. Every picker PTY test on test (windows) fails with:

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

That is a crossterm keyboard-enhancement error: the picker (via skim 5.3.1) drives keyboard-enhancement handling that the legacy Windows console API doesn't support, crashing the picker at runtime. ~40 switch_picker tests fail as a result.

Evidence it's skim 5.3.1

• chore: bump skim from 5.1.0 to 5.3.1 #3526 (bump skim 5.1.0 → 5.3.1) merged with its own full-tests (windows) already red — the regression landed on main unnoticed.
• main at skim 5.1.0 (0958a365b) was green on test (windows) the same day. The only relevant change between that green run and the failures is the skim bump.
• The failure is a picker runtime crash, unrelated to any picker source change — no switch_picker code moved.

Since it's on main, it reddens Windows CI for every open PR (e.g. #3346), not just one branch.

Fix

Pin skim = "=5.1.0" in Cargo.toml — the last Windows-green release — with a comment naming the regression.

Cargo.toml specified skim = "5.0" (a caret range that 5.3.1 satisfies), so #3526 changed only the lockfile. A lock-only revert would silently drift back to 5.3.1 on the next cargo update, so the hold has to live in the manifest. The lockfile downgrade (skim 5.3.1 → 5.1.0, frizbee 0.11.0 → 0.10.0 and the deps that pulls) follows from the pin.

Unpin once skim's keyboard-enhancement path is guarded for the legacy Windows console (upstream fix, or a worktrunk-side guard before enabling enhancement).

Testing

• cargo run -- hook pre-merge --yes — full suite green locally (4475 passed, 1 skipped), including the switch_picker tests that fail on Windows at 5.3.1.
• CI will confirm test (windows) returns to green.

This was written by Claude Code on behalf of Maximilian Roos

[worktrunk-bot]

The default-branch CI failure on run 29896809898 (from #3529 merging) is the same skim 5.3.1 regression this PR fixes — full-tests (windows) fails across the switch_picker suite with Keyboard progressive enhancement not implemented for the legacy Windows API, and the build log shows Compiling skim v5.3.1. Not opening a separate fix PR; this PR's skim = "=5.1.0" pin covers it.

Heads up: #3537 is a prior bot ci-fix PR pinning the same =5.1.0 — a duplicate of this one, so it can be closed once this lands.

[worktrunk-bot]

The pin is correct and well-justified: =5.1.0 is the last Windows-green skim line, the manifest comment explains the hold, and the lockfile downgrade (skim 5.3.1 → 5.1.0, frizbee 0.11.0 → 0.10.0, color-eyre re-added) follows from it. test (windows) and full-tests (windows-2022, windows) are green here, confirming the picker crash is resolved.

One process note — this duplicates #3537 (the tend-ci-fix PR fix/ci-29884002914), which makes the identical skim = "=5.1.0" change from the same root cause. Worth closing one as a duplicate. If keeping this one, #3537's manifest comment is a bit more specific about the mechanism (skim 5.3.0's unconditional PushKeyboardEnhancementFlags in tui/backend.rs::execute_enter, and why 5.2.0 is skipped for border-default snapshot churn) — you may want to fold that detail in before merging.