[ruff] Do not simplify round() calls (RUF046)

[InSyncWithFoo]

Summary

Part 1 of the big change introduced in #14828. This temporarily causes all fixes for round(...) to be considered unsafe, but they will eventually be enhanced.

Test Plan

cargo nextest run and cargo insta test.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

Thanks for splitting the PR!

I think the rule is now over eager in removing int calls from rount

[InSyncWithFoo]

For reference, here's the logic table for round() cases:

number	ndigits	round()	Error/fix
Literal int	Not given	int	Safe
Literal int	Literal int	int	Safe
Literal int	None	int	Safe
Literal int	Other	Other	-
Literal float	Not given	int	Safe
Literal float	Literal int	float	-
Literal float	None	int	Safe
Literal float	Other	Other	-
Inferred int	Not given	int	Unsafe
Inferred int	Literal int	int	Unsafe
Inferred int	None	int	Unsafe
Inferred int	Other	Other	-
Inferred float	Not given	int	Unsafe
Inferred float	Literal int	float	-
Inferred float	None	int	Unsafe
Inferred float	Other	Other	-
Other	Not given	Likely int	Unsafe
Other	Literal int	Other	-
Other	None	Likely int	Unsafe
Other	Other	Other	-

[MichaReiser]

Nice table: From testing a few cases, it seems that round(4, ndigits=10) always returns an int

>>> round(4, 10)
4
>>> type(_)
<class 'int'>

But we should not create a diagnostic if ndigits isn't an integer, e.g. round(4, 10.4)

[MichaReiser]

Nice. This looks good now, except that we can also provide a safe fix if the number is an int, and ndigits is any integer.

[InSyncWithFoo]

Logic changed and table updated. round(0, integer) and round(inferred_integer, integer) are now both fixable, safely and unsafely correspondingly.

[MichaReiser]

Perfect, thank you