Cross-Seed: at exact size, match a group alone against the same group with its collective ("- Kyo)" vs "- Kyo Mura)")

[illutr0n]

What: at the identical byte size, let a group written alone match the same group with its collective appended, as an exact-size relaxation that's hash-checked before seeding:

	Name	rls group
Local	Example Show (2020) Season 1 S01 (1080p BluRay x265 HEVC 10bit AAC 5.1 Kyo)	Kyo
Candidate	Example Show (2020) S01 (1080p BluRay x265 SDR AAC 5.1 English - Kyo Mura)	Kyo Mura

Today this is group/site mismatch. Some trackers name these releases by the encoder alone, others by encoder and collective. Real case: a season pack, identical size to the byte on both trackers. #3283 matches the collective when it's written as the site (- Kyo) [Mura]), but not when it's left out entirely.

I see the #3283 corpus pins this exact pair as no match on purpose (space-joined group and collective against the group alone), so I'm asking whether that could be relaxed for the exact-size case only, not strict matching:

• Only at exact size, as a group relaxation. Strict matching stays as it is, and a size difference stays a rejection on every path.
• Hash-checked before seeding: a group mismatch relaxation already requires verification (searchRelaxationRequiresVerification), so a wrong pairing fails the recheck instead of seeding bad data.
• Narrow: both names without a site, one group exactly equal to the first word of the other's two-word group. A different encoder (Other Mura) or the collective alone (Mura) still doesn't match.

I run this as a local patch on v1.33.0: a check next to spaceJoinedGroupSite in validateExactSizeSearchIdentity, recorded as an observed group difference and neutralized to the shared group in replay. In the corpus, the identical-size row becomes an allowed difference on the search, retry and webhook paths, and a new row with the same names 50 MB apart stays no match on every path. Happy to share the diff if it's useful.

If keeping it strict is deliberate (an encoder publishing different encodes under both names?), that's fine too. I'd just like to understand the case it protects against.