[Phoenix500526]

Which issue does this PR close?

Related to #24098. This PR addresses the output schema metadata mismatch.

Rationale for this change

When UNION inputs have different schema-level metadata, output batches can retain the metadata of their original inputs even though the UNION declares a merged schema. Consumers inspecting the returned batches therefore see incomplete or conflicting metadata.

For example, the existing regression test produces a batch with shared: input0, while the declared output schema contains shared: input2 and metadata keys from all three inputs.

What changes are included in this PR?

• Use ProjectionExec::try_new_with_schema_metadata in coerce_schema to apply the merged schema metadata to the projection output.
• Strengthen test_union_schema_metadata_and_nullability to compare complete output batch schemas instead of only their fields.

What is the testing strategy for this PR?

The strengthened test fails before the fix and passes afterward across all five nullability combinations. It also verifies that output values are preserved.

Passed locally:

• cargo fmt --all
• cargo clippy --all-targets --all-features -- -D warnings
• The workspace extended test command from AGENTS.md, including all 545 SQLLogicTest files.

Are there any user-facing changes?

UNION output batches now carry the merged schema-level metadata declared by the plan. Values and row counts are unchanged. There are no public API changes.

[Phoenix500526]

cc @kosiew Could you take a look at this follow-up to #24098? #24094 already moved UNION/INTERLEAVE schema alignment into physical planning, but the projection still inherits each input’s schema-level metadata instead of the merged metadata. This PR fixes that remaining output metadata mismatch and strengthens the existing test to compare complete batch schemas.

[kosiew]

@Phoenix500526,

Thanks for the fix. The metadata-aware projection constructor is the right approach, and the strengthened regression test confirms that output batches expose the merged schema metadata. I found no correctness regression or public API break.

The important boundary is schema coercion, where the UNION's declared metadata should become authoritative for emitted batches. Enforcing this at construction time also covers INTERLEAVE without introducing runtime batch rewriting or additional execution branches. Existing projection machinery preserves metadata overrides through rebuilding and prevents unsafe projection elimination.

I have an optional integration-coverage suggestions, non blocking.

[kosiew]

@Phoenix500526,

Thanks for addressing the follow-up coverage request. The metadata-aware projection correctly preserves the merged UNION schema on emitted batches, and the expanded regression tests verify complete schema equality while retaining the existing nullability and value checks.

The construction-time coercion boundary remains the right place for this fix. It keeps schema ownership with the shared UNION and INTERLEAVE machinery, avoids runtime metadata adapters, and preserves existing execution semantics without introducing public API changes.

I verified that the new identical-field case exercises plain Column coercion when only schema-level metadata differs. My previous comment is addressed, and I found no remaining issues requiring changes.