/bisect: find the commit that introduced a regression with git bisect run

When something worked last week and fails now, `git bisect` finds the commit that broke it in a logarithmic number of steps. The hard part is writing a check that reliably exits 0 for good and non-zero for bad on every commit in between. `/bisect` handles that.

**What it does** 1. Confirms the working tree is clean (bisect checks out old commits) and asks before stashing anything. 2. Confirms the bad ref (default `HEAD`) and a known good ref, and verifies both by running the check on each first. 3. Writes a check script in `.git/bisect-check.sh` (outside the tracked tree, so checkouts do not touch it). The script installs dependencies only if the lockfile changed, runs the narrowest test or command that shows the bug, and exits `125` for commits that cannot be tested (for example, build failures unrelated to the bug), which tells git to skip them. 4. Runs `git bisect start <bad> <good>` and `git bisect run .git/bisect-check.sh`. 5. Reads the first bad commit's diff and explains which change most likely causes the regression. 6. Always runs `git bisect reset` at the end, including on failure, and restores any stash.

**What it will not do** It will not bisect without verifying that the good ref passes and the bad ref fails, since a check that does not separate them gives a meaningless answer. It does not fix the bug automatically; it offers to once the cause is clear.

**Example** `/bisect v2.4.0 "npx vitest run tests/export.test.ts"` Result: 212 commits, 8 steps, first bad commit `a1b2c3d refactor(export): stream rows`, which changed the CSV writer to drop the trailing newline.