fix(title): keep the title when alternative_title is excluded

[Sanjays2402]

closes #927

--excludes alternative_title disabled TitleFromPosition outright, so guessit returned no title at all for any filename. The exclusion now only skips the alternative-title split, and the whole title hole is kept as title (Star Wars - The Mandalorian and Grogu).

While fixing it I also had to copy match_tags when tagging the hole rather than aliasing the rule's own list — the split path had been hiding that, and without the copy the shared list accumulated tags across parses and corrupted a later unrelated filename.

Regression case added to enable_disable_properties.yml; it fails on develop and passes with the fix, and the full suite is green.

This change was prepared with AI assistance; the regression test was run locally and fails without the fix.

[Toilal]

Good catch, and the second half of the diff is a better find than the PR body lets on. I merged develop into the branch locally and measured it before reviewing, since no CI ran here.

Verification

• Full suite after merging current develop: 2482 passed, 4 skipped. pytest -m cross_parser green, ruff/mypy clean.
• Behaviour diff over 2921 names (yaml corpus + cross-parser datasets) in auto mode: 0 changes — the fix is properly confined to the excludes/includes paths.
• The blast radius is wider than described: on develop, --exclude alternative_title also killed episode_title (Show.Name.S01E02.The.Episode.Title returned neither title nor episode_title), and --includes title returned {}. Both work now.

Findings

1. hole.tags = list(...) fixes a state leak across guessit() calls — please call it out

I reproduced it by dropping the copy from your branch:

match_tags start: ['title', 'equivalent-ignore']
Movies/Foo (2019)/Foo.2019…  → rule.match_tags=['title', 'equivalent-ignore', 'equivalent-ignore']
Bar.2020.720p.mkv            → rule.match_tags=['title', 'equivalent-ignore', 'equivalent-ignore', 'equivalent-ignore']

PreferTitleWithYear's AppendTags(["equivalent-ignore"]) does match.tags.extend(...) (rebulk rules.py:218) on the rule instance's own list, which the cached rebulk shares across every parse. After that, every title produced is born tagged equivalent-ignore, which processors.py:80 reads. Latent on develop (the split path hid it), live as soon as this change lands. The copy belongs exactly where you put it — in TitleBaseRule, so EpisodeTitleFromPosition is covered too.

2. That fix has no test

A yaml entry parses a single string, so it structurally cannot catch cross-parse contamination. A small Python test that runs two guessit(..., {"excludes": ["alternative_title"]}) calls in a row and asserts the second title is untagged (or that match_tags is still ["title"]) would keep the copy from being refactored away silently.

3. Worth pinning: --includes title

It now returns title: "Movie Name 2019 1080p BluRay x264-GRP mkv" — the title hole spans everything, since nothing else is matched to bound it. Consistent with what includes means, and better than the previous {}, but an entry in enable_disable_properties.yml would make the expectation explicit.

4. Nit

Two independent fixes in one commit. Both are justified, and the PR body explains it — but the aliasing fix stands on its own merit and would have read better as its own commit.

Happy to merge once (2) is in.

---

_{Review measurements produced with Claude Code assistance.}

[Toilal]

Heads up: I pushed to your branch directly rather than round-tripping the review — maintainerCanModify was on, so:

1. Rebased onto current develop (no conflicts). Force-pushed, so git fetch && git reset --hard origin/fix/exclude-alternative-title-keeps-title before you touch it again.
2. 0096646 — a regression test for the list(self.match_tags or []) copy, in test_api.py next to the sibling state-leak test. It parses three times in a row with --exclude alternative_title and asserts the rule's own match_tags is still ["title"]. Reverting your copy turns it red with assert ['title', 'eq...alent-ignore'] == ['title'].
3. e09ecc6 — pinned --include title in enable_disable_properties.yml (it used to return {}; the title now spans the whole name, since nothing else is matched to bound the hole).

The tags copy is the part worth highlighting: it is a genuine cross-parse state leak, latent on develop because the split path hid it, and live the moment titles = [hole] becomes reachable. Good instinct to fix it rather than route around it.

Also note the failing build jobs you saw were not your fault: semantic-release exits non-zero on the detached merge commit of a pull_request checkout. Fixed on develop (05cfcd7), and this run picks it up.