BUG: Raise on coercion of ambiguous datetime strings to datetime64

[iabhi4]

This PR addresses a bug where object-dtype arrays containing ambiguous datetime strings (e.g., "12/01/2020", "13/01/2020") were being silently coerced to datetime64[ns], potentially resulting in inconsistent or unintended parsing.

• Introduced stricter input validation during coercion to detect and raise a ValueError when an ambiguous format is inferred but cannot be consistently parsed.

• Added tests to cover both direct assignment and constructor-based coercion scenarios.

• closes 61353

• Tests added and passed

• All code checks passed

• Added an entry in the latest doc/source/whatsnew/v3.0.0.rst file

[iabhi4]

The pre-commit is currently failing due to the unwanted-patterns-private-import-across-module hook

This PR imports _guess_datetime_format_for_array from pandas.core.tools.datetimes, which is a private function.
There’s currently no public alternative that offers this functionality. specifically, inferring a consistent datetime format from an array of strings without coercion.

Happy to refactor this if needed, for example, by moving it to a shared utility module or discussing exposing it publicly if that makes more sense long-term

[iabhi4]

Closing this PR as the current approach doesn’t feel quite right from a design and maintainability perspective. I believe there might be a cleaner solution that avoids adding complexity across multiple layers