Cross-seed apply drops a strict search match when info.name omits the listing REPACK flag

This was generated by AI during triage.

Agent Brief

Category: bug Summary: A strict search match fails at apply when the info.name of the downloaded torrent lacks a version flag (REPACK/PROPER/RERIP) that the Torznab listing title carried.

Current behavior: Search classifies the listing title against the existing torrent as searchCandidateClassStrict, because both names carry REPACK. The decision has no RelaxedDifferences and no StrictChecksumReplay. At apply, FindCandidates compares the parsed info.name of the downloaded .torrent with the existing torrent through namedReleasesMatchWithReasonAndTitles. The info.name has no REPACK, so the pair fails with mismatch reason REPACK. The strict class has no replay branch for a failed apply prefilter, so the candidate is dropped and the add reports no_match ("No matching torrents found with required files"), even when the single file has the same byte size. Manual match works.

The checksum case already has a replay: StrictChecksumReplay with oneSidedChecksumIsOnlyStrictDifference keeps a strict decision alive when info.name only lacks the CRC.

Desired behavior: When the search decision for this source hash is strict and the listing title carried the same version flag as the existing torrent, an info.name that omits that flag, with no other strict difference, does not drop the candidate at the release prefilter. File size and layout checks still decide. A version flag that info.name carries and the listing title did not, or a flag that conflicts (REPACK vs PROPER, REPACK2 vs REPACK), still rejects.

Key interfaces:

• searchCandidateDecision / searchDecisionProvenance: may need a replay token for a one-sided version flag, next to StrictChecksumReplay.
• classifySearchCandidate(): records the token only when the listing and the existing torrent agree on the flag.
• FindCandidates() apply prefilter: today keeps no candidate for a strict decision whose apply mismatch is REPACK; must keep it when the token is set and the flag is the only strict difference.
• searchDecisionRequiresVerification(): decides whether this path forces a recheck.

Acceptance criteria:

• Listing ... REPACK [Group], existing ... REPACK [Group], info.name without REPACK, equal single-file size: apply finds the candidate.
• Same pair where info.name also differs in another strict attribute (resolution, group, source): apply still rejects.
• Listing without REPACK and info.name without REPACK against an existing REPACK torrent: search and apply still reject.
• Conflicting flags (PROPER vs REPACK, REPACK2 vs REPACK): still reject.
• Season pack behavior around REPACK stays as today.
• Match corpus rows cover the new cases.

Out of scope:

• Relaxing the REPACK/PROPER rule for webhook, RSS, or any match path without a search decision.
• The bracketed-flag parse bug tracked in #3292.

Domain:

• Glossary terms: Match path, Read release. Gap: no term for replaying a search decision when the listing title and info.name differ (the concept that StrictChecksumReplay already uses).
• ADRs: 0008 (the rule stays a pure matcher method that reads names and files).
• Owner: the matcher search-decision replay (classifySearchCandidate plus the apply prefilter in FindCandidates).

Logs:

• None

Why a human: Design: Should a version flag that the listing carries and info.name omits be replayed like the one-sided checksum, and if so, must it require exact-size evidence, a forced recheck, or both? A REPACK and a non-REPACK can be different payloads, and the Match path rule says every path gives the same verdict unless the corpus lists the difference.

From discussion #3302