GFQL remote: test generated client wire against old and current server handlers #2248

Why

pygraphistry #1955 / PR #2244 exposed a test-boundary miss: client tests asserted that Let/Cypher requests contained gfql_operations=[], locking in a valid identity fallback on older servers. #2244 fixes the client wire and adds HTTP response mocks. Those tests prove request construction/error mapping, but no maintained test sends the generated request through both a server handler that lacks gfql_query and one that supports it. Existing graphistry server dual-mode tests predominantly send gfql_operations and do not cover this cross-version Let boundary.

Acceptance

• Pin exact client source and old/pre-DAG plus current server handler/image revisions. Use an actual serving route/handler or a faithful hermetic route fixture with a documented source mapping; do not use a mocked requests.post response as the sole proof.
• Exercise public client Let, serialized Let, compiled Cypher Let, and nonempty flat Chain through the same transport. Prove supported server returns hand-computed changed rows and old unsupported server yields typed HTTP/remote error for Let, never a plausible identity graph. Flat Chain remains accepted by both where supported.
• Include a negative invalid/missing query-type case that sends no request, plus JSON and parquet response paths where they affect the wire contract. Record exact source, handler route, response code, row oracle and engine for each cell. Treat unsupported engines as explicit typed declines/skips rather than coverage.
• Keep the lane deterministic and credential-free; live Hub deployment acceptance is separately gated on server owner/provenance issues and does not substitute for this contract test. Scope the smallest repeatable lane in the repo that owns the runnable server harness, linking the paired repository if needed.

This is a follow-on to #2244's client fix, not a reason to hold an otherwise green exact-head repair absent a new wrong-answer repro.