fix date_bin overflows scaling extreme Timestamp(Second) source

[xiedeyantu]

Which issue does this PR close?

• Closes panic: date_bin overflows scaling extreme Timestamp(Second) source #22211.

Rationale for this change

date_bin could panic during planning or constant evaluation when scaling a non-nanosecond source timestamp to nanoseconds overflowed. This change makes that path return a regular error instead of panicking.

What changes are included in this PR?

• Added checked overflow handling for source timestamp scaling in date_bin.
• Return an error for out-of-range source timestamp conversion instead of panicking.
• Preserved existing NULL behavior for unrelated out-of-range date_bin cases.
• Added Rust unit test and sqllogictest coverage for the overflow case.

Are these changes tested?

Yes.

Verified with:

• cargo test -p datafusion-functions test_date_bin --lib
• cargo test -p datafusion-sqllogictest --test sqllogictests date_bin_errors

Are there any user-facing changes?

Yes. Queries that previously could panic now return a normal error:

Execution error: DATE_BIN source timestamp ... cannot be represented in nanoseconds

[xiedeyantu]

@nathanb9 Thanks for your review. All comments have been revised according to your suggestions. Please confirm if this is what you expected.

[nathanb9]

I think this is better way to handle it too @xiedeyantu Thanks for fixing quickly.

FYI im not a committer so youll need someone else as well.

[xiedeyantu]

I think this is better way to handle it too @xiedeyantu Thanks for fixing quickly.

FYI im not a committer so youll need someone else as well.

Thanks all the same.

[xiedeyantu]

@Dandandan Could you help me take a look?

[xiedeyantu]

@Jefffrey I tried to fix it, but I'm not sure if it's what you want. Could you take a look?

[Jefffrey]

cc @kumarUjjawal I think this will overlap with your PR

• fix: handle date_bin negative subsecond and overflow cases #22610