fix(codec): point strict refusal at the sender, not the receiver

The previous refusal text told the operator to "re-encode the bytes
with inlining enabled" — but the operator seeing this error is the
receiver, whose session has inlining off. The receiver cannot re-encode
bytes it did not produce; only the sender can.

Reword to direct the fix at the side that can apply it: ask the sender
to re-encode with inlining disabled (the by-name form a strict
receiver actually accepts), or register the UDF on the receiver and
enable inlining on both sides. Phrase preserves the
"inlining is disabled" substring the strict-mode test asserts against.

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

Author: timsaucer

crates/core/src/codec.rs

@@ -353,10 +353,10 @@ fn refuse_inline_payload(kind: &str, name: &str) -> datafusion::error::DataFusio
     // error would mis-route it into "fix your SQL" buckets.
     datafusion::error::DataFusionError::Execution(format!(
         "Refusing to deserialize inline Python {kind} '{name}': Python UDF \
-         inlining is disabled on this session. Re-encode the bytes with \
-         inlining enabled, or register '{name}' on the sender's session \
-         before encode (and on the receiver before decode) so the UDF \
-         travels by name."
+         inlining is disabled on this session. Ask the sender to re-encode \
+         with inlining disabled (so the UDF travels by name), or register \
+         '{name}' on this receiver's session and enable inlining on both \
+         sides — receivers cannot re-encode bytes they did not produce."
     ))
 }