the suffix search continues instead of starting again at _1

Every file renamed onto one name probed stem_1, stem_2, ... from the
beginning, so N files cost N^2/2 Exists calls - a test here counts 1890
of them for 60 files. The search now continues from the highest suffix
already tried for that stem.

Within one plan that is the same answer: the taken set only grows while
a plan is built and the disk is not being written to, so a suffix taken
once stays taken. Proved rather than argued - with same_1 and same_3
already on disk and same_2 free, both versions put a file in the gap,
and the two plans are byte-identical.

  1500 files renamed to one name: 2.63s -> 0.05s

1 files changed, 2 insertions, 2 deletions

diff --git a/internal/plan/enum_test.go b/internal/plan/enum_test.go
index 21f6a63..fee279e 100644
--- a/internal/plan/enum_test.go
+++ b/internal/plan/enum_test.go
@@ -62,7 +62,7 @@ func TestEveryConflictPolicyIsPlanned(t *testing.T) {
 					t.Errorf("config.%s is not planned: %v", name, r)
 				}
 			}()
-			resolveConflict(Move, config.Conflict(i), "/r/a.pdf", "/r/b.pdf", d, claimed{})
+			resolveConflict(Move, config.Conflict(i), "/r/a.pdf", "/r/b.pdf", d, newClaimed())
 		}()
 	}
 	defer func() {
@@ -70,5 +70,5 @@ func TestEveryConflictPolicyIsPlanned(t *testing.T) {
 			t.Error("an unknown conflict policy did not panic")
 		}
 	}()
-	resolveConflict(Move, config.Conflict(len(policies)), "/r/a.pdf", "/r/b.pdf", d, claimed{})
+	resolveConflict(Move, config.Conflict(len(policies)), "/r/a.pdf", "/r/b.pdf", d, newClaimed())
 }