Serve >=51% likely-resolve questions in the WTC feed

[WilfordGrimley]

Description

Implements the owner-ratified question-feed serving policy from the
2026-07-24 WTC vote-queue data brief: the served question mix now
prioritizes likely-resolve 1-click printing questions at ≥51% of served
questions when supply exists, falling back to the pre-existing
three-tier ranked union otherwise. This is a selection-layer change
only — zero changes to vote_consensus.py's weights, thresholds, or
gates (D1/D4 mechanisms untouched); is_likely_resolve_printing calls
the real resolve_weighted_consensus, it never reimplements its
arithmetic.

1. LIKELY-RESOLVE classification (is_likely_resolve_printing):
   for a card's current highest-weighted printing outcome group, adds
   one hypothetical VoteSource.USER-weight vote and re-runs the real
   resolver to check whether that group now wins — the brief's own
   exact-code simulation approach (the same method that produced its
   46,310-card LIKELY-RESOLVE SUPPLY figure). Compute-per-serve, no
   caching layer — see _likely_resolve_printing_card's docstring for
   the cost/approach tradeoff this accepts.
2. Mix composition: get_next_question_feed_item serves from the
   likely-resolve pool whenever this session's served-mix ratio is
   below settings.QUESTION_FEED_LIKELY_RESOLVE_MIX_RATIO (default
   0.51) and the pool has supply for this voter; otherwise falls
   through to the existing tier 1 → tier 2 → tier 4 ranked union
   unchanged, with one addition inside tier 4: cards whose latest Stage
   D scan-log origin is a "quick-negative" reason
   (unknown-set-code/eliminated/border-mismatch/frame-mismatch)
   are now prioritized over the harder/open-ended remainder (secondary
   tiebreak, after the pre-existing -vote_count ordering, never ahead
   of it). Per-voter exclusion and existing tier semantics preserved.
3. Mix logging: every served item (either pool) is recorded in a
   new QuestionFeedServedLog model (anonymous_id, pool,
   question_type, origin_reason, served_at) — the
   bias-conditioning record the data brief's SOUNDNESS NOTE calls for,
   so a future audit can correlate click behavior against a session's
   easy-question exposure. Migration 0079_questionfeedservedlog.py
   (hand-written and verified via manage.py makemigrations --check
   against a local venv — no live DB/container was touched to produce
   it).
4. Docs: docs/features/printing-tags.md's "Unified question feed"
   section updated in place with the new "Mix-composition policy"
   bullet (soundness citation, mix-log description, quick-negative
   ordering rationale).

Checklist

• I have installed pre-commit and installed the hooks with pre-commit install before creating any commits.
• I have updated any related tests for code I modified or added new tests where appropriate.
• I have manually tested my changes as follows:
  • Ran the full backend test suite locally (pytest . against a
    fresh testcontainers Postgres/ES, via a local venv — no live
    production DB/containers touched): 1931 passed, 4 skipped
    (skips are the pre-existing named ones), 0 failed.
  • cardpicker/tests/test_question_feed.py alone: 40 passed (25
    pre-existing + 15 new), including likely-resolve classification
    round-tripped against the real resolver (1-away resolves,
    2-away doesn't), mix-ratio gating (below/at target), graceful
    degradation with no likely-resolve supply (no hang/exception,
    ratio drops honestly), per-voter exclusion on the new pool, the
    served-mix log rows, and the quick-negative tier-4 reordering
    (including the deliberate "ambiguous" exclusion).
  • manage.py makemigrations cardpicker --check --dry-run reports
    "No changes detected" against the new model — the hand-written
    migration is verified to exactly match models.py.
  • pre-commit run (ruff/isort/black/mypy/prettier) clean on all
    changed files.
• I have updated any relevant documentation or created new documentation where appropriate.

Deviations from spec

• None from the task's numbered items. One scoping decision: the
  "near-threshold multi-candidate" slice of the brief's remainder
  ranking is naturally covered by the same is_likely_resolve_printing
  classification (it doesn't distinguish single- vs multi-candidate —
  both are just "current leading group, one vote away"), so it lives in
  the likely-resolve pool rather than as a separate remainder tier; the
  remaining two remainder slices (quick-negative to-review, then
  hard/open-ended) are implemented as described inside tier 4.

Open items

1. Migration was hand-written and verified offline (makemigrations --check) rather than generated via manage.py makemigrations
   against the live mpcautofill_django container, since running that
   command against the live container was blocked by this session's
   own tooling guardrail. Verified exact-match against the model state;
   flagging so a reviewer can independently confirm before merge.
2. No deploy-freeze was active at task start (deploy-freeze-active
   label check was empty) — this PR includes a migration, so please
   check freeze status again before merging/deploying if time has
   passed.