VALUES list rejects mixing an extension-typed value with its bare storage type ("Inconsistent metadata across values list") #26917

Describe the bug

A standalone VALUES list fails to plan when one row carries extension-type metadata and another row is the bare storage type, even though the storage types match:

Error during planning: Inconsistent metadata across values list at row 1 column 0. Was FieldMetadata { inner: {"ARROW:extension:name": "arrow.uuid"} } but found FieldMetadata { inner: {} }

The same values are accepted by INSERT INTO <uuid table> VALUES (...), which plans VALUES against the target schema.

Found while reviewing #21714. The check lives in LogicalPlanBuilder on main and reproduces there with the test-only UUID type planner in cast_extension_type_metadata.slt, so it predates that PR.

To Reproduce

On #21714 (or in cast_extension_type_metadata.slt on main):

VALUES (CAST(X'00010203040506070809000102030506' AS UUID)), (X'00010203040506070809000102030507');
-- Error during planning: Inconsistent metadata across values list at row 1 column 0 ...

Expected behavior

This is arguably a usability gap rather than a correctness bug: an explicit error is better than silently picking a type. But other systems unify these:

• Postgres: VALUES ('...'::uuid), ('...') → column typed uuid.
• DuckDB: same, column typed UUID.

Possible behavior: when the storage types match and the only difference is that some rows have no metadata, use the extension type (as a cast), instead of erroring.