BUG: Raise on coercion of ambiguous datetime strings to datetime64
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.

- [x] closes 61353  
- [x] Tests added and passed
- [ ]  All code checks passed
- [x] Added an entry in the latest `doc/source/whatsnew/v3.0.0.rst` file  
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 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