docs(gfql): memory note for call_mode auto bridge (G5 decision)

Document why there is no per-call size cap on the off-engine bridge: the transient copy
is the same allocation as running the analytic on engine='cudf' directly, a row count is
a poor memory proxy, and the real cap belongs at the RMM/container/deployment layer. Point
memory-conscious users at call_mode='strict' or RMM/container limits. (G5 decision: reject
a row-cap knob as the wrong mechanism — see plan PHASE 13.)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: lmeyerov

docs/source/gfql/engines.rst

@@ -375,6 +375,17 @@ always will). Under ``engine='polars'`` / ``'polars-gpu'`` GFQL runs them as a
   bridging — for benchmark integrity (no hidden modality switch attributed to the
   Polars engine) or a hard memory ceiling.
 
+.. note::
+   **Memory on a very large graph.** The bridge materializes a copy of the graph in
+   the off-engine format — pandas (host) for ``polars``, cuDF (device / unified
+   memory) for ``polars-gpu``. That transient copy is the *same* allocation you'd
+   incur running the analytic on ``engine='cudf'`` directly, so GFQL does **not** add
+   a per-call size cap (a row count is a poor memory proxy, and the real cap belongs
+   at the RMM / container / deployment layer). For a graph large enough that the copy
+   is a concern, either set ``call_mode='strict'`` (decline the bridge) or run the
+   analytic under an RMM device-memory limit / container memory limit, exactly as you
+   would for any cuDF workload.
+
 This is **deliberately narrower** than traversal / filter / row ops (``hop``,
 ``WHERE``, ``RETURN`` …), which stay **parity-or-``NotImplementedError``** and are
 never bridged — a bridge there would hide a missing native impl and misreport