perf(integration): detect squash merges past the 500-commit cap without the cost of #4100 - #4437

…stead of giving up

## The problem

With the path filter, the patch-id scan still gave up entirely when more
than `PATCH_ID_SCAN_MAX_COMMITS` target commits touch the branch's paths.
That happens when a branch edits a hot file: on the GitOps repo from the
previous commit, 8 squash-merged branches edit values files a bot
re-touched 1,079–1,669 times since, so they were reported as not
integrated.

## The fix

List the candidates oldest first (`rev-list --reverse`) and diff the
first `PATCH_ID_SCAN_MAX_COMMITS` of them instead of none. The cut is made
in Rust: `--max-count` applies before `--reverse`, so it would keep the
newest.

A squash merge lands on the target soon after the branch forks, and
updating the branch before merging (a rebase, a merge from the target)
moves the merge-base up to just before it. What piles up behind it is
the target's later edits to the same files. For all 8 branches above,
the squash commit was the oldest candidate.

Nothing changes up to the cap. Past it, a check now diffs
`PATCH_ID_SCAN_MAX_COMMITS` patches where it used to diff none, which is
the cost the cap already allowed for a branch just under it. Every match
is still an exact patch-id match, so it adds no false positives; it only
finds squash merges the old bail skipped. On that repo, all 27 branches whose
merged PR head equals the local branch tip are now detected, and the 4
remaining branches are genuinely unmerged (2 closed PRs, 1 without a PR,
1 whose tip differs from the merged head).

Still missed: a squash that landed after more than
`PATCH_ID_SCAN_MAX_COMMITS` other commits to the branch's files, counted
from the merge-base. That takes a branch left un-updated while the
target edited its files hundreds of times, then squash-merged as is; by
then the target has usually changed the patch's context lines too, so no
patch-id would match anyway.

## Tests

The fixture now takes padding before and after the squash:

- `detects_squash_among_oldest_candidates_past_cap` (was
  `bails_when_commits_touching_branch_paths_exceed_cap`): 500 same-file
  pads after the squash no longer hide it.
- `misses_squash_past_oldest_candidates`: 500 same-file pads before the
  squash push it past the cap.
- `detects_squash_behind_commits_to_other_paths` (was
  `detects_squash_when_only_other_paths_exceed_cap`): the other-file pads
  move before the squash, since after it an unfiltered oldest-first scan
  would find it too and the test would stop pinning the path filter.
- `branch_paths_are_literal_not_pathspec_magic`: likewise moved before.

Claude-Session: https://claude.ai/code/session_01XwVSv9XpxotCADuKxRyUbA

…free

Review follow-ups on the path-limited patch-id scan.

- The branch's paths are now read as raw bytes (`run_command_output`)
  and passed to `rev-list --stdin` unchanged. `run_command` decodes
  stdout lossily, so a non-UTF-8 filename reached the pathspec as
  U+FFFD, matched nothing, and filtered the squash commit out — a
  regression against the unfiltered scan. The comment claiming "any
  filename survives" is now true.
- `rev-list` gains `--no-merges`. `diff-tree` emits no patch for a
  merge and a squash merge has one parent, so every merge kept by
  `--full-history` only took a slot under the cap.
- `branch_paths_are_literal_not_pathspec_magic` uses `[o]the[r]`
  instead of `*`, which git on Windows rejects as a path
  (`fatal: invalid path '*'`). As a pathspec the bracket expressions
  still match `other`; `typos` flags `[o]ther`.

New tests:

- `non_utf8_branch_paths_still_filter`: a Latin-1 `café.txt` behind
  `PATCH_ID_SCAN_MAX_COMMITS` pads on another file. Fails with a lossy
  decode, and would fail with a fall-back-to-whole-range fix too.
- `branch_path_with_line_break_scans_whole_range`: fails without the
  line-break guard, which would split the path into two pathspecs.
- `branch_that_changes_nothing_is_not_squash_merged`: covers the early
  return.

The first two are Unix-only: Git for Windows refuses control
characters in paths, and a Windows checkout can't hold a non-UTF-8
name.

Claude-Session: https://claude.ai/code/session_01XwVSv9XpxotCADuKxRyUbA

…alone

The `typos` pre-commit hook rewrote the fixture's `caf\351.txt` to
`calf\351.txt`, in both the literal and the `build` doc comment, so the
test comment's `café.txt` named a file the test never built. Use
Latin-1 `été.txt` (`\351t\351.txt`) instead, which typos doesn't
touch, and spell the literal out in the comment.

Claude-Session: https://claude.ai/code/session_01XwVSv9XpxotCADuKxRyUbA

…h-limited-scan

# Conflicts:
#	src/git/repository/mod.rs

… path

The path-limited `rev-list` had no bound: it walked all of
`merge-base..target` with every branch path as a pathspec, so its cost
grew with range × path count. On git.git over a 10,000-commit range
(no commit-graph, same machine load for each), one path took 1.5 s,
30 paths 16 s, and 1,659 paths 182 s. It reran every time the target
moved, which on a fast-moving repo is constantly.

- Filter on one path. `git patch-id` hashes each file's name with its
  change, so a commit with the branch's patch-id touches every path the
  branch changed, and any one is a sound filter. Prefer a file the
  branch added: the target can't touch it before the squash, so the
  squash is its oldest candidate. A path with a line break is never
  chosen; a branch whose every path has one falls back to the range.
- Bring back the `rev-list --count` pre-flight, at 10,000 commits
  (`PATCH_ID_SCAN_MAX_RANGE`) instead of 500. It is graph-only and
  stays around a tenth of a second at that size. The GitOps repo that
  prompted this PR had branches 600–5,600 commits behind, all inside it.
- `PATCH_ID_SCAN_MAX_COMMITS` becomes `PATCH_ID_SCAN_MAX_CANDIDATES`,
  since there are now two caps.
- The name-status listing goes through `PlumbingDiff::Tree`, so
  `submodule.<name>.ignore=all` no longer hides a gitlink path from it,
  and reads raw bytes through `run_command_bytes`.
- `wt remove`'s help states both caps as behavior, not internals.

Tests: `filters_on_a_path_the_branch_added`, `detects_squash_at_range_cap`
and `skips_scan_past_range_cap`. Each fails against the mutation it pins
(no added-path preference, no pre-flight, `>=` for `>`) and only it.

The patch-id result was cached only per (branch SHA, target SHA), so a
stale conflicting branch paid the whole scan again every time the target
moved: on a clone of this repo with a branch 2,000 commits behind that
conflicts on `src/cli/mod.rs` (228 candidates), about 1.15 s per
`wt list` after each new commit on main.

- A new `patch-id-scan` cache kind, keyed on (branch, merge-base, cap),
  records the target the scan reached, how many candidates it diffed,
  and whether one matched. When that target is an ancestor of the
  current one, the next check scans only `scanned_target..target`
  against what is left of the 500-candidate cap. A match, or a miss
  that used up the cap, answers before any walk, the range pre-flight
  included. Any other cached target means a fresh scan. On the same
  clone, `wt list` after a target move drops to 0.31 s.
- When no target commit touches the filter path, return before the
  branch-side diff and the patch-id pipeline.
- A `rev-list --count` output that doesn't parse is an error rather
  than 0, which would have lifted the range cap.

A resumed scan counts earlier candidates first, where a fresh scan
orders by commit date, so the two can disagree on which candidates fall
inside the cap after a merged-in side branch. That moves how far back
the check reaches, never whether a match is real. The sha_cache spec
and the list caching table now describe the kind as progress rather
than a pure SHA-pair result.

Tests: `no_candidates_records_scan_without_diffing`,
`resumes_scan_as_target_moves_forward`,
`exhausted_scan_stays_negative_as_target_moves`,
`rescans_when_cached_target_is_not_an_ancestor` and
`cached_match_holds_past_range_cap`.

…h-limited-scan

# Conflicts:
#	src/git/repository/mod.rs

Each patch-id candidate became a full `diff-tree -p` patch, and the
branch side a second pipeline, so a conflicting branch cost seven git
processes and every candidate's whole patch. In a monorepo where target
commits touching the filter path also touch many other files, that was
most of the scan.

`git patch-id` hashes every line of a file's patch header except
`index`, including each file's `diff --git` line and its mode lines.
So one `diff-tree --stdin -r -z --raw` over the candidates, which diffs
trees but reads no blobs, settles most of them:

- A candidate whose changed paths aren't exactly the branch's can't
  match, however small the extra change (a mode flip or an empty file
  included).
- A candidate whose every path has the branch's modes and blob ids
  produces the branch's patch byte for byte, so it matches.
- Only the rest go through `diff-tree -p | patch-id`, in one pass with
  the branch's own diff, given as `<branch> <merge-base>` on stdin.

The branch side's `--name-status` listing becomes `--raw --no-abbrev`
in the same process, so the common squash costs three processes and no
patches. Answers are the PR's: on clones of a GitOps repo and a
monorepo, `wt step prune --dry-run` lists the same branches as before,
and `wt list` marks the same ones integrated.

`run_command_with_stdin` becomes `run_command_bytes_with_stdin`, since
the raw output carries paths as bytes.

Tests: `detects_squash_onto_a_file_edited_since_the_fork` and
`rejects_different_change_to_the_same_paths` reach the patch-id pass,
as `detects_squash_merge_under_nondefault_diff_config` now does too:
its target edits a distant line before the squash, which otherwise
matches by blob id and never builds a patch.
`parses_raw_diff_with_and_without_commit_ids` and
`classifies_candidates_by_raw_changes` cover the parsing and the rules.

…-prefilter

# Conflicts:
#	src/git/repository/integration.rs