[pyupgrade] Remove mentions of variance related to fix safety (UP040, UP047) (astral-sh#29592)

Mentioned in astral-sh#29486

Removes the incorrect descriptions from UP040 and UP047 that mention
variance. This was purely decorative and never had any function, so
removing it is perfectly safe.

No further clarification added - variance is quite complicated and the
user doesn't need to know about (decided in the issue).

This is my first PR here, so I probably did something wrong while making
it and I am open to all feedback.

---------

Co-authored-by: Brent Westbrook <36778786+ntBre@users.noreply.github.com>

Author: FrancescoPezzella

crates/ruff_linter/src/rules/pyupgrade/rules/pep695/non_pep695_generic_function.rs

@@ -32,14 +32,11 @@ use super::{DisplayTypeVars, TypeVarReferenceVisitor, check_type_vars, in_nested
 ///
 /// ## Fix safety
 ///
-/// This fix is marked unsafe, as [PEP 695] uses inferred variance for type parameters, instead of
-/// the `covariant` and `contravariant` keywords used by `TypeVar` variables. As such, replacing a
-/// `TypeVar` variable with an inline type parameter may change its variance.
-///
-/// Additionally, if the rule cannot determine whether a parameter annotation corresponds to a type
-/// variable (e.g. for a type imported from another module), it will not add the type to the generic
-/// type parameter list. This causes the function to have a mix of old-style type variables and
-/// new-style generic type parameters, which will be rejected by type checkers.
+/// This fix is marked unsafe because the rule may be unable to determine whether a parameter
+/// annotation corresponds to a type variable (e.g. for a type imported from another module). In
+/// that case, the fix does not add the type to the generic type parameter list. This causes the
+/// function to have a mix of old-style type variables and new-style generic type parameters, which
+/// will be rejected by type checkers.
 ///
 /// ## Example
 ///

crates/ruff_linter/src/rules/pyupgrade/rules/pep695/non_pep695_type_alias.rs

@@ -29,10 +29,6 @@ use super::{
 /// support for generics.
 ///
 /// ## Known problems
-/// [PEP 695] uses inferred variance for type parameters, instead of the
-/// `covariant` and `contravariant` keywords used by `TypeVar` variables. As
-/// such, rewriting a type alias using a PEP-695 `type` statement may change
-/// the variance of the alias's type parameters.
 ///
 /// Unlike type aliases that use simple assignments, definitions created using
 /// [PEP 695] `type` statements cannot be used as drop-in replacements at
@@ -62,8 +58,8 @@ use super::{
 ///
 /// ## Fix safety
 ///
-/// This fix is always marked unsafe because it can change runtime behavior and type-checking
-/// semantics, as described above. It may also remove comments.
+/// This fix is always marked unsafe because it can change runtime behavior, as described above.
+/// It may also remove comments.
 ///
 /// The rule also cannot inspect type variables defined in another module. For `TypeAlias`
 /// annotations, this means the fix may fail to convert legacy type variables to type parameters,