`ComposedPhysicalExtensionCodec` implements only 6 of the 12 `PhysicalExtensionCodec` methods

[timsaucer]

Describe the bug

ComposedPhysicalExtensionCodec overrides six of the twelve methods on PhysicalExtensionCodec:

try_decode        try_encode
try_decode_udf    try_encode_udf
try_decode_udaf   try_encode_udaf

The remaining six fall through to the trait defaults:

try_decode_udwf                     try_encode_udwf
try_decode_expr                     try_encode_expr
try_decode_higher_order_function    try_encode_higher_order_function

Every one of those decode defaults is not_impl_err!. So composing codecs that individually support window UDFs, physical expressions, or higher-order functions produces a codec that supports none of them — the composition silently narrows what its members could do.

The encode defaults are worse than inert for the by-name pair, since try_encode_udwf returns Ok(()) writing nothing while try_decode_udwf errors. A window UDF therefore encodes "successfully" and fails on the way back.

To Reproduce

Compose any codec that implements try_encode_udwf / try_decode_udwf and serialize a plan containing a window UDF. The composed codec never forwards to it, and decoding fails with PhysicalExtensionCodec is not provided for window function <name>.

Expected behavior

ComposedPhysicalExtensionCodec forwards every method of the trait it implements, so composing codecs is capability-preserving.

Additional context

The fix looks mechanical — the existing encode_protobuf / decode_protobuf helpers already handle the position framing, and the six missing methods follow the same shape as the six present ones. Happy to open a PR.

Found while evaluating ComposedPhysicalExtensionCodec for use in datafusion-python (apache/datafusion-python#1678).

Source: datafusion/proto/src/physical_plan/mod.rs, impl PhysicalExtensionCodec for ComposedPhysicalExtensionCodec at line 1974.

Related: #24830 — a separate defect in encode_protobuf on the same type.