ComposedPhysicalExtensionCodec is unsound #16980

Describe the bug

Current implementation of ComposedPhysicalExtensionCodec is unsound. Approach relying on try_any may produce a wrong type by accident if types are simple enough.

This is not just theoretical issue, it happened in ballista codec, where encoded parquet file was decoded as csv instead of parquet. Type was encoded by the last encoded in the list but decoded by first encoder just by pure luck. ( I guess i don't have to mention how hard this was to debug)

In order to make current implementation sound we would need to capture which encoder in the list has been used and do a reverse lookup when we do decoding. We need to encode tuple (position, serialised_blob).

To Reproduce

I dont have a reproducer at the moment, i believe it could be done very simple

Expected behavior

It is expected that types can't be decoded by accident

Additional context

No response