E-2: backend zero-hit printing-filter degradation

[WilfordGrimley]

Description

Fixes live behavior today: a printing-specific decklist paste (e.g. Moxfield's (SET) NUM suffix, or E-1's <set>/<collectorNumber> XML import) silently finds nothing when nobody's uploaded an image for that exact printing yet — even though the card exists under other printings. search_functions.get_search applies expansion_code/collector_number as a hard Elasticsearch .filter("term", ...); zero hits under that filter meant zero hits, full stop.

retrieve_card_identifiers now retries once, without the printing filter, whenever the filtered search returns zero hits and a printing filter was actually supplied — and reports a degraded flag. Exact-match behavior when hits DO exist under the filter is completely unchanged — this is a zero-hit fallback only, never a boost/re-rank weakening (_resolved_printing_match_tier untouched).

EditorSearchResponse gains degradedQueries: string[] (hash keys whose search degraded), threaded through the schemas/ JSON-Schema → quicktype → Python/TS pipeline. Backend-only in this PR — frontend badge consumption ("image unavailable, matched printing instead" style UI) is natural follow-up work, not wired here.

Testing note (please read before reviewing the test diff)

This sandbox has no working Docker daemon (confirmed: dockerd fails to start with a permission error) — the existing pytest suite's testcontainers-based Postgres/Elasticsearch fixtures (conftest.py) can't run here, despite a bare Postgres 16 cluster being available on the host (started it, confirmed it doesn't help — the fixtures need their own ephemeral containers regardless). This matches this repo's own documented cloud-session constraint.

What I verified instead:

• A standalone script that imports the real search_functions module directly (bypassing the Docker-dependent conftest.py entirely) and exercises retrieve_card_identifiers's retry logic against a mocked _retrieve_card_identifiers_once — 4 scenarios (hits found/no retry, zero hits/retries+degrades, no filter supplied/no spurious retry, expansion_code-only still retries), all passing.
• mypy/black/isort/ruff run locally at the exact versions pinned in .pre-commit-config.yaml (isort 5.12.0, black 22.8.0, mypy 1.7.0, ruff 0.0.257) — 0 new errors on every touched file; confirmed the 4 pre-existing mypy errors that do show up are all in files this PR never touches (models.py, tag_consensus.py, mtg.py).
• py_compile on every touched Python file.
• npx tsc --noEmit on the frontend (the regenerated schema_types.ts compiles clean; nothing currently reads the full EditorSearchResponse shape, only .results, so this is a safe additive change on the frontend side today).

New pytest coverage is included (test_search_functions.py: 4 new tests on the retry/degrade decision in isolation; test_views.py: 2 existing snapshot tests updated for the correct new behavior + 1 new multi-query test asserting degradedQueries tracks per-query, not globally) along with hand-patched snapshot fixtures (test_views.ambr — 25 purely-additive degradedQueries: [] entries, plus the 2 existing "no results" tests corrected to reflect that they now find the card via the degraded fallback). I wrote these to match the exact syrupy snapshot format already in the file, cross-checked against ~25 existing examples, but they have not been executed.

Merge-time checklist

• Run the full test_search_functions.py/test_views.py pytest suite in a real environment with Docker (or CI) to confirm the hand-authored snapshot entries are byte-correct and every new test actually passes. DONE (2026-07-18, real Docker/testcontainers on the host, not this sandbox): 845 passed, 4 failed (2 pre-existing moxfield-flake, 2 pre-existing missing-client_secrets.json - both confirmed via a bare-master control run, unrelated to this PR). Found and fixed a REAL regression during this gate: the new test_only_the_actually_degraded_query_is_flagged_among_several test shifted factory.Sequence counters for 6 downstream, unrelated snapshot tests (TestGetSampleCards/TestNewCardsFirstPages/TestNewCardsPage/TestPostExploreSearchResults) - fixed via a name-gated module-level autouse fixture that insulates just the new test (d7e4653c; documented as a troubleshooting.md variant, 01bc1fdf). 130/130 snapshots pass after the fix, zero .ambr regeneration needed. Schema regeneration also verified consistent: npx tsx quicktype.ts output diffed against committed schema_types.py/schema_types.ts - identical modulo pre-commit formatting (black/prettier/isort import order), including the new degradedQueries field.
• Re-scoped to POST-DEPLOY, DONE (2026-07-18, after this PR merged + backend redeploy - b884a779 baked as GIT_SHA, confirmed via /2/info/ health check and showmigrations before/after): curled the live 3/editorSearch/ endpoint (post_editor_search, this PR's own function) with a printing-specific query guaranteed to zero-hit under the filter - {"query": "Brainstorm", "cardType": "CARD", "expansionCode": "ZZZ"} ("ZZZ" is not a real expansion code, same technique this PR's own test_only_the_actually_degraded_query_is_flagged_among_several uses). Response: {"degradedQueries": ["key1"], "results": {"key1": ["10H3ZbWslBZlNnYFUpZfNU5pxLBx-lI6v", "101iJliFXUOgp-GXXf4Du7nE3t-3HtxyQ", "1R4kpXBng-uRY5JsUeFkhBTbEnwmdDAiM", "1R6v5gjF4Bu5rktuomvkp2OXQd0IcQwuR"]}} - same 4 results as the unfiltered name-only search, key1 correctly flagged in degradedQueries. Confirmed against the real production Elasticsearch index, not fixture data.

---

Generated by Claude Code