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

**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 `.

**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` (https://github.com/apache/datafusion-python/pull/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.