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

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!