fix(question_feed): phase-C not-official-art routing + md5-expand artist/tag exclusions

[WilfordGrimley]

Summary

Two independent routing gaps in the question feed (MPCAutofill/cardpicker/question_feed.py),
diagnosed against reason_tags.py's WTC phase B partition and issue #473's md5 identity groups:

1. reason_tags.py (item 1): promotes the WTC phase B "not-official-printing" vs.
   "not-official-art" partition from prose in the module docstring into two real, checked
   frozensets — NOT_OFFICIAL_PRINTING_REASON_TAGS / NOT_OFFICIAL_ART_REASON_TAGS — mirroring
   the frontend's NoMatchReasonStrip.tsx NO_MATCH_REASON_TAG_GROUPS. A new test asserts they
   are exhaustive and disjoint over NO_MATCH_REASON_TAGS, the same invariant
   NoMatchReasonStrip.spec.ts asserts on the frontend side.

2. question_feed.py (item 2, phase C routing): a card carrying a positive
   (VotePolarity.APPLY) CardTagVote for a not-official-art tag has had its artwork question
   declared unanswerable by a human, so the feed now excludes it from artist-shaped questions in
   both _tier_2_contested and _tier_4_fresh (_not_official_art_card_ids, md5-group-widened,
   computed once per feed request in get_next_question_feed_item). The printing question is
   unaffected. The exclusion requires a human-backed source
   (vote_consensus.is_human_backed_source), not merely "any positive vote" — see the commit
   message for the reasoning behind that judgment call.

3. question_feed.py (item 3, md5 expansion): _tier_2_contested's artist and tag own-vote
   exclusions are now md5-group-widened (_voter_answered_artist_card_ids /
   _voter_answered_tag_card_ids_by_tag), so a voter who answered one member of a byte-identical
   group is not re-asked the identical artist/tag question under a sibling's identifier — the
   same convention _voter_answered_printing_card_ids already established for the printing
   tiers. The tag widening is scoped to the CARD axis only (never the tag axis), preserving
   _tier_2_contested's existing per-tag granularity, and costs one query total (not one per
   review pair) plus one md5 expansion per distinct tag the voter has touched. Per the
   engineering brief, this is scoped to _tier_2_contested only — _tier_4_fresh's own
   artist/tag own-vote exclusions keep their pre-existing, unwidened form (see Open items below).

Observation (out of scope, no implementation): local_illustration. _eligible_illustration_cards_queryset (the machine illustration calculator) has no awareness of
NOT_OFFICIAL_ART_REASON_TAGS either, and plausibly warrants the same exclusion for the same
reason phase C does. Left as a follow-up, not implemented here.

Test plan

• test_reason_tags.py run alone — 10 passed (includes 3 new tests for the partition's
  exhaustiveness/disjointness and the external-ip group membership)
• test_question_feed.py run alone — 50 passed (includes 4 new tests in
  TestPhaseCNotOfficialArtRouting: positive not-official-art excludes the artist question,
  not-official-printing doesn't, a negative vote doesn't, a machine-cast vote doesn't)
• test_md5_group_pooling.py run alone — 72 passed (includes 6 new tests in
  TestPhaseCAndTierTwoMd5Expansion covering artist/tag md5 widening, sibling
  non-re-serving, the per-tag-axis regression _tier_2_contested's existing comment warns
  against, and the not-official-art group-wide exclusion; plus a computed-once-per-feed-
  request pin for all three new exclusions extending the existing 2026-07-25 PR Pool printing-consensus votes across md5 identity groups #482
  condition f1 test)
• All three touched test files run together — 132 passed (no order-dependence per issue
  Test suite is order-dependent: leaked fetch-failure window trips the envelope across files (8 failures on master) #679's concern)
• python -m py_compile on all five changed files — clean
• mypy — zero new errors; the two pre-existing question_feed.py hits (lines 158/583) and
  reason_tags.py's zero-error baseline are both untouched by this change (repo-wide baseline
  is ~290 django-stubs related-manager errors across 20 files, none introduced here)
• pre-commit run over the five changed files — all green (black reformatted one test file
  on the first pass; re-ran clean after)
• Full backend CI suite (deferred to CI — not run locally in full per the brief's scope)

Task-end checks (CLAUDE.md)

• Docs convention: no docs/ reference file describes this feed's routing behavior in a way
  that needs updating in place (the design is captured in question_feed.py's own
  docstrings, which this PR extends)
• Wiki maintenance: this changes the question feed's serving behavior (backend routing only,
  no new user-visible UI or admin action) — no wiki page needs <change> for a
  user-invisible routing fix; confirming this judgment stands as owner review proceeds
• Extractable-primitives ledger: no primitive extracted or destroyed by this change
• Constant renames: no module-level constant renamed, extracted, moved, or retired
• Push policy: branch pushed, PR opened against master, not merged

CI gate fix: constant_rename_equivalence.py false positive on pure additions

The "Renamed constants are behaviour-preserving" check was failing on this
PR itself: scope_modules() computed the set of "renamed/removed" constant
names as a symmetric difference between base and head declarations, so
a constant added at head with nothing removed anywhere (this PR's two new
NOT_OFFICIAL_PRINTING_REASON_TAGS / NOT_OFFICIAL_ART_REASON_TAGS) pulled
reason_tags.py and test_reason_tags.py into the whole-module equivalence
comparison. Since base never declared those names, the modules can never
normalise identically — this failure mode is unpassable by construction for
any PR that merely adds a matching-pattern constant.

Fix: the affected-name set now uses base − head (names that disappeared
from base) instead of the symmetric difference, matching the function's own
pre-existing docstring ("modules that touch a constant whose DECLARED NAME
changed"). Renames and removals are still fully scoped and checked — only
pure additions with nothing removed anywhere in the same module drop out.

One real tradeoff surfaced and is accepted, not hidden: an isolated
literal-to-constant extraction (no companion rename/removal in the same
module) is no longer auto-checked for a wrong extracted value, because it is
provably indistinguishable, by name-diffing alone, from a harmless new
constant backing brand-new logic — the exact shape that caused this PR's
false positive. In practice this capability was only ever exercised when a
companion rename existed in the same module (verified against PR #567's own
history), which remains fully covered; the isolated case is pinned as a
documented, deliberate limitation in
test_an_isolated_extraction_with_a_wrong_value_is_a_known_scope_blind_spot.

• Gate script run against this PR's actual base/head — exit 0 (was 4)
• test_constant_rename_equivalence.py alone — 49 passed
• Full .github/scripts/tests/ suite together — 214 passed (order-
  independence per issue Test suite is order-dependent: leaked fetch-failure window trips the envelope across files (8 failures on master) #679)
• python -m py_compile on both touched files — clean
• pre-commit run on both touched files — clean (black reformatted the
  test file on the first pass; re-ran clean after)