BUG: Series.round with pd.NA no longer raises; coerce object+NA to nullable float and round; add test (#61712)

Summary: 
Fixes Series.round raising TypeError for object-dtype Series containing pd.NA by coercing to nullable Float64 before rounding, preserving pd.NA values.

Description:
This PR fixes an issue where calling Series.round on an object-dtype Series containing pd.NA would raise a TypeError.
The method now attempts to safely cast to the nullable Float64 dtype before rounding, preserving pd.NA values.

Includes:

Bug fix in Series.round to coerce object with pd.NA to Float64 and round as expected.

New test in test_round.py covering the case of object-dtype Series with pd.NA.

Added changelog entry in doc/source/whatsnew/v3.0.0.rst.

 closes #61712

 [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests)

 All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit)

 Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) (N/A – no new functions/args)

 Added an entry in the latest doc/source/whatsnew/v3.0.0.rst file
Simpler to just operate point wise? > Simpler to just operate point wise?

Thanks for the feedback! I went with the dtype coercion approach since it keeps the operation vectorized and avoids Python-level iteration, which I assumed would be more consistent with how similar numeric conversions are handled in Pandas.

A pointwise implementation could definitely work for handling pd.NA cases explicitly, but I was aiming to minimize performance overhead and preserve existing behavior for other object-typed numeric data. If you think a pointwise approach would be preferable for clarity or maintainability here, I’m happy to prototype it so we can compare. The trouble with the casting approach is it only works in castable cases.  Things like Decimal objects don't fit that. > The trouble with the casting approach is it only works in castable cases. Things like Decimal objects don't fit that.

Thanks for pointing that out, I see what you mean about the limitation with non-castable types like Decimal. That’s a good case where the dtype coercion approach wouldn’t behave correctly.

I can prototype a pointwise implementation so we can compare behavior and performance, and make sure it handles cases like Decimal properly. If the trade-offs look acceptable, we could go with that approach to ensure correctness across all object-typed inputs.

Would you prefer I push that as an additional commit here, or open a separate PR so we can compare more cleanly? Just update this PR