docs(codec): clarify strict-mode security scope

The doc on `with_python_udf_inlining(false)` said strict mode "rejects
cloudpickle.loads on untrusted from_bytes input", which could be misread
as making `pickle.loads(untrusted)` safe. It does not.

Strict mode only narrows the codec layer: it stops `Expr::from_bytes`
from invoking `cloudpickle.loads` on the inline `DFPY*` payload. The
outer pickle stream is still arbitrary code — `pickle.loads` honors any
`__reduce__` the bytes name, and an attacker is free to choose one.

Spell that out in the doc so callers don't treat the toggle as a
substitute for "never pickle.loads untrusted input." The Python-side
docstring (`SessionContext.with_python_udf_inlining`) already carries
the equivalent caveat; this brings the Rust side in line.

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

Author: timsaucer

crates/core/src/codec.rs

@@ -149,6 +149,18 @@ impl PythonLogicalCodec {
     /// when the codec sits on a session that must produce
     /// cross-language wire bytes, or reject `cloudpickle.loads` on
     /// untrusted `from_bytes` input.
+    ///
+    /// Security scope: strict mode (`false`) protects only the codec
+    /// layer — it stops `Expr::from_bytes` from invoking
+    /// `cloudpickle.loads` on the inline `DFPY*` payload. It does
+    /// **not** make `pickle.loads(untrusted_bytes)` safe. Python's
+    /// pickle protocol permits arbitrary code execution via
+    /// `__reduce__` (and `Expr.__reduce__` returns
+    /// `Expr._reconstruct(bytes)` — an honest reducer here, but the
+    /// outer pickle stream can contain any reducer). Treat every
+    /// `pickle.loads` on untrusted input as unsafe regardless of this
+    /// setting; the toggle only narrows the surface inside
+    /// `from_bytes`.
     pub fn with_python_udf_inlining(mut self, enabled: bool) -> Self {
         self.python_udf_inlining = enabled;
         self