perf(gfql): project count-path polars filters to id columns (round 4) - #1853

Review rework pushed — point by point:

1. polars-only projection → generalized: one _filter_project(frame, match, project, engine=...) serves every engine. polars keeps the fused lazy filter+select; pandas/cudf pre-narrow to project + the match keys present on the frame, filter, then cut to project — missing match keys stay missing so filter_by_dict raises its usual typed error. Same at-most-these-columns contract everywhere.
2. CI red → it was the type-hygiene ratchet (my new helper's bare dict annotation, 23>22). Fixed (Dict[str, Any]); guard green locally; CI re-dispatched.
3. alias issue on other engines → yes, the hazard class existed beyond polars. Generalized projection removes the payload-column shape uniformly (a __in_count__ data column never reaches any counting path now); the endpoint-binding shape (src/dst literally named like a counter) survives projection by design and is value-pinned per engine — pandas/cudf/polars all return the degree-product oracle on both shapes.
4. getattr prologue → replaced with typed Plottable attribute access (base_graph._nodes etc. are declared on the protocol); the identical prologue existed in a sibling fast path and got the same fix. mypy clean, no new casts.
5. insight placement → the count-shape⇒id-columns knowledge now lives in _filter_project's docstring with call sites referencing it. The general home is logical-plan column pruning (compute per-op column needs once in the IR so every path inherits narrow scans, subsuming per-call-site project=) — filed as question 9 in the typed-ontology design doc for your call, since it's planner work beyond this PR.
6. shallow tests → added: a differential matrix (pandas/polars/cudf × 7 filter shapes incl. predicate-on-decoy, missing-column and E302 error paths — narrow must equal full-cut-to-columns, and both arms must raise the same exception type), per-engine projection-width pins, per-engine reserved-name value pins (both shapes), and a cache-key separation pin (same match, different projection, one store → two entries, no cross-contamination). 1,692 green in the DGX container including the cudf and polars-gpu arms.

🤖 Generated with Claude Code

Re: when to project — the answer shipped in the follow-up commit: WHEN must be a static plan property, never a runtime cost call, and that's only sound if projection is monotone (never costlier than the plain filter). The first pandas/cudf arm wasn't: pre-narrowing paid an upfront full-height copy of the projected columns, which loses on selective filters over narrow frames (exactly the q8 edge shape). Now:

• polars: fused lazy filter+select (was already monotone).
• pandas/cudf: filter_by_dict's mask logic is extracted as filter_mask_by_dict (same column resolution, same typed errors, same 3VL membership — filter_by_dict itself now composes from it), and the narrow arm does .loc[mask, project]: identical mask work, strictly fewer gathered columns.

With both arms monotone, the admission rule is simply: a caller passes project iff its plan provably reads only those columns — documented in _filter_project's docstring. The count path qualifies today; grouped-aggregate paths could declare ids + referenced props next; and the general home (per-op column requirements computed once during logical-plan compilation, so every path and the generic executor inherit narrow scans) is filed as typed-ontology question 9 for your call.

🤖 Generated with Claude Code