Fix union equivalence schema rewrite with stale constants

[xudong963]

Which issue does this PR close?

• Closes UnionExec can panic when stale equivalence constants are rewritten after projection #23374.

Rationale for this change

UnionExec::try_new can panic while computing equivalence properties if stale constant metadata is carried across a projection and then rewritten to the union output schema.

In the observed shape, a filter such as ticker = 'ESU6' can leave a uniform string constant in equivalence properties. After a parent projection drops ticker, union property schema rewriting can see the remaining column slot as a timestamp column and attempt to cast 'ESU6' to Timestamp, which fails during planning.

Equivalence constants are optimizer metadata, so an unrepresentable constant after schema rewrite should be discarded rather than failing query planning.

What changes are included in this PR?

• Drops a uniform constant during EquivalenceProperties::with_new_schema if its value cannot be cast to the rewritten expression type.
• Removes trivial equivalence classes after dropping such constants.
• Propagates UnionExec::compute_properties errors from UnionExec::try_new instead of unwrapping.
• Adds a regression test for union equivalence schema rewrite with an unrepresentable stale constant value.

Are these changes tested?

Yes:

Are there any user-facing changes?

No API change. This prevents a planner panic for affected UNION ALL + filter + projection query shapes.

[kosiew]

@xudong963
Thanks for the targeted fix.
The unit test covers the stale metadata case well, and I have one small follow-up suggestion that is not blocking.

[kosiew]

Nice targeted test for the stale metadata state. As a follow-up, it may be worth adding a higher-level regression test that builds the filter/projection/union plan shape from the original issue and checks that UnionExec::try_new or physical planning succeeds. That would help protect the full path that produced the stale constant, not just the calculate_union boundary.

[xudong963]

Thanks, that makes sense. The current test intentionally targets the exact stale-metadata boundary in calculate_union. I agree a higher-level regression would be useful, especially if we can capture the original filter/projection/union shape reliably. Since the reduced issue does not include a concrete SQL repro and the normal projection path should drop removed-column constants, I’ll keep this PR focused and consider adding a UnionExec::try_new/planner-level regression as a follow-up.