Broken git clean between scenarios: untracked residue leaks into undo commits, can produce spurious 0/0/0 verdicts

[AdamoHamou]

Summary

Working-tree cleanup between scenarios never actually runs, so untracked files created by
one scenario survive into the next. git add -A then folds that residue into the next
scenario's undo commit, which is what gets cherry-picked — in the worst case yielding a
conflict-free 0/0/0 for a scenario whose PR content was never integrated. Results become
order-dependent.

Mechanism

1. Residue is created (inherent, not itself a bug): the invert/replay operations use
   IntelliJ refactoring processors that write files into the clone — e.g. inverting a
   class move/rename creates a file at the old path. After the next checkout that file is
   untracked, so git reset --hard can't remove it.

2. Cleanup is a no-op, integration/utils/GitUtils.java:67-70:

   Utils.runSystemCommand("git", "clean");
   Git.getInstance().reset(repo, GitResetMode.HARD, "HEAD");

   Two independent defects: no -f (clean.requireForce defaults to true, so git
   refuses and does nothing), and runSystemCommand
   (integration/utils/Utils.java:28-33) never sets pb.directory(...), so it runs in
   the IDE process's CWD, not the clone. GitThread's reset --hard + forced checkout
   (repatch/utils/GitUtils.java:291-305) also leaves untracked files in place. No code
   path runs a working git clean.

3. Residue is committed: addAndCommit()'s git add -A
   (repatch/utils/GitUtils.java:285) sweeps the residue into rightUndoCommit
   (repatch/RePatch.java:138), which is cherry-picked at repatch/RePatch.java:152.

Confirmed the effect empirically: scenarios that score 0/0/0 in a sequential run
instead reproduce plain git cherry-pick's exact conflict counts when re-run alone on a
pristine clone, and their undo commits contain files byte-identical to ones written by
earlier scenarios' inversions. data is in google drive