Capped sweeps re-tread the same candidate prefix forever

[Erilla]

Question

discoverFingerprintMatches orders candidates with [...roster].sort(compareCandidates), which sorts by canonical character id — plain alphabetical. Nothing persists which candidates a sweep tested, by design (Retention and compact signature for fingerprint material keeps fingerprint material transient and stores no cursor or candidate list).

Those two properties combine badly. The live shurkle sweep spent its 300-request cap on the first 296 of 392 candidates and published fingerprint_sweep_capped. When its seven-day cadence expires, the next sweep re-fetches the same roster, sorts it the same way, spends the same cap on the same prefix, finds the same 12 alts, and stops in the same place. The remaining 96 members are not "not yet reached" — they are unreachable, however many times the sweep runs.

The map assumed reach was bounded by matcher cost against the shared budget. It is actually bounded by a fixed cap meeting a fixed ordering, which is a smaller and permanent bound.

Raising the cap above the roster size fixes it for a given guild but not in general: guilds reach 1000 members, and cap size trades directly against sweep throughput because each sweep reserves its full cap up front.

To decide — what ordering serves discovery, given only a prefix of it will run:

• Name similarity to the root. For shurkle this would have found Shurkdotalot, Shurkdrood, Shurkmonk, Shurkpala, Shurkvoker, Shurkweave within the first handful of requests. Cheap, no persistence, and matches how players actually name alts — but it biases against alts named unlike the main, and a sweep that "found nothing" would then mean something narrower than before.
• Level descending. Prioritises mains and geared alts, deprioritises the bank alts the feature was partly meant to find.
• Rotate the starting offset per sweep. Successive sweeps cover different slices, so coverage accumulates over weeks. Needs a persisted offset per root, which brushes against the no-cursor constraint and would need that decision revisited.
• Leave alphabetical. Simple and deterministic, but permanently blind past the cap.

Note that any ordering other than a full sweep changes the meaning of a non-match: it becomes "not found within the budget we chose to spend", not "not related". That matters because the public alt list does not distinguish discovery method or confidence.

Found while running the first live sweep on test; see also #30.