fix(weave): refuse code-bearing custom objects on server-side decode

[gtarpenning]

Summary

• Server-side workers (the evaluate-model worker) reconstruct user-supplied objects. A small set of custom types deserialize by loading code (the Op custom type, and anything that falls back to a load_op), which is fine for a normal client but not for a server worker acting on someone else's payload.
• Adds a per-client policy WeaveClient.allow_unsafe_custom_obj_decode (default True). The decode path (custom_objs._decode_custom_obj) consults it via the ambient client and refuses to reconstruct code-bearing custom types when it's off. The worker flips it off, so every payload it touches is covered, including dataset rows materialized lazily during evaluation.
• Decode-time guard means a single choke point rather than pre-scanning each payload; the shared is_safe_to_decode predicate is pure and unit-tested. The worker also rejects op refs passed directly as the evaluation/model ref (client.get would load and run them before decode applies).
• Tracking: WB-34909

Testing

unit tests for is_safe_to_decode and the object-ref guard, a sync check that every KNOWN_TYPES entry is consciously classified safe-or-Op, plus an end-to-end evaluate-model test where an Op row in a dataset is refused at decode time.

[codecov]

Codecov Report

❌ Patch coverage is 91.22807% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...orkers/evaluate_model_worker/payload_validation.py	90.56%	2 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[gtarpenning]

Superseded by #7004 (branch renamed to drop the leaked ticket ref; the rename closed this PR).