Provide typed evaluate_bounds for date_bin and from_unixtime

Is your feature request related to a problem or challenge?

date_bin and from_unixtime use the default evaluate_bounds, which returns an unbounded interval with DataType::Null. Downstream property analysis therefore cannot recover their output type from the interval.

With the conservative ordering check in #25409, date_trunc cannot propagate ordering through these unknown ranges even when the actual output is a timezone-free timestamp. For example, date_trunc('hour', from_unixtime(c)) can retain an unnecessary sort when c is ordered and the session timezone is unset.

Describe the solution you'd like

Provide typed evaluate_bounds for date_bin and from_unixtime where the output type can be determined reliably. The interval may remain unbounded; precise value bounds are not required to recover this optimization.

Preserve the correct timestamp unit and timezone, including explicit and session timezones for from_unixtime, and supported time types for date_bin. If the available inputs do not establish the output type, keep the result unknown rather than assuming it is timezone-free.

Add tests for timezone-free and timezone-aware outputs, and SQL coverage for ordering propagation through date_trunc. Include the named-timezone regression from #25409 to ensure necessary sorts remain present.

Describe alternatives you've considered

Keep unknown intervals and retain the conservative ordering behavior. More broadly, expression type information could be made available independently of bounds analysis, but that would involve a wider design change.

Additional context

Follow-up to the review of #25409. This addresses missing type information in bounds analysis. Recognizing safe timezone-aware inputs such as UTC and fixed offsets in date_trunc is a separate optimization.

Related: #25464 tracks recognizing safe timezone-aware inputs in date_trunc, such as UTC and fixed-offset timestamps.