github actions: Update interdiff for bug fixes and post-rework refinement

This version of interdiff's --fuzzy feature was stress tested on 1,426,898
kernel commits, in the commit range of v2.6.12-rc2..7dff99b. It was
stressed by passing the same patch for both patch arguments to interdiff,
and checking for empty output (which is expected). Only 87 out of those
1,426,898 commits didn't work correctly with --fuzzy mode, mostly due to an
abundance of non-unique lines changed (e.g., several chunks of empty lines
deleted), which causes the split-hunk approach to produce an incorrect
result. Since these are extreme edge cases and the failure rate is 0.006%,
they are considered to be correct. There is no way to fix those 87 commits
without degrading the --fuzzy feature's quality and correctness.

This stress test was conducted with the new stress-test-fuzzy.sh script in
the patchutils repo.

---

Here is a complete summary written by Claude of what's changed:

- Fewer false rejections when comparing patches: interdiff --fuzzy would
  sometimes report hunks as rejected even when the two patches make
  identical changes. This was caused by internal hunk splitting producing
  sub-hunks with unbalanced context that the patch utility couldn't locate.
  Split hunks now always have balanced context. Additional edge cases were
  fixed for hunks at the very start or end of a file, and a crash when a
  split hunk ends with an addition line was also fixed.

- Files ending without a trailing newline: The "\ No newline at end of
  file" marker was not handled during hunk splitting, corrupting the output
  and causing false rejections. When comparing reverted patches, the marker
  would also incorrectly strip the trailing newline from the preceding
  line, producing a bogus difference. Both are fixed.

- File creations and deletions: Patches that create or delete a file (one
  side is /dev/null) would crash or produce spurious rejected hunks. These
  now skip the fuzzy path entirely.

- Mode-only and metadata-only patches: Patches with only mode changes,
  binary diffs, or commit metadata (no diff hunks) would trigger a false
  "doesn't contain a patch" error. These are now recognized as valid inputs
  with no diffable content.

- Code cleanup: Internal data structures were reworked for correctness and
  efficiency (length-tracked line buffers, O(1) list appends, dead code
  removal). No user-facing behavior changes.

- Testing: A stress-test script (tests/stress-test-fuzzy.sh) is included
  for mass-testing against every commit in a git range. Validated against
  ~1.43M Linux kernel commits with 87 failures (0.006%), all from known
  limitations.

Author: kerneltoast

.github/workflows/validate-kernel-commits.yml

@@ -189,7 +189,7 @@ jobs:
       - name: Clone and build custom patchutils
         run: |
           # Security: Pin to specific commit to prevent supply chain attacks
-          EXPECTED_COMMIT="d90325ceaa8835b85db56ded37cf3407377078db"
+          EXPECTED_COMMIT="b0090afd47557515b423e05be66494a4d5429fad"
 
           # Clone repository at the specific commit we want
           git clone https://github.com/kerneltoast/patchutils.git --depth=1 --revision="$EXPECTED_COMMIT"