fix: reinfer never type in array repeat expressions

[phpont]

Array repeat expressions could produce false-positive type mismatches when the initializer diverged and the element type still had to be inferred from later context.

The issue was that infer_expr could constrain the fresh inference variable to ! too early. I switched this path to the existing infer_expr_suptype_coerce_never helper, which also matches how rustc handles the never-type coercion in this case.

I also added a minimal regression test next to the existing never-type reinference tests.

rustc reference per ai policy

In rustc_hir_typeck::FnCtxt::check_expr_repeat, when there is no expected element type, rustc creates a fresh inference variable and checks the repeated element with check_expr_has_type_or_error.

check_expr_has_type_or_error explicitly handles a resulting ! by applying a NeverToAny adjustment before checking the subtype relation with demand_suptype_diag.

The change here follows the same behavior by using rust-analyzer's existing infer_expr_suptype_coerce_never path instead of constraining the fresh inference variable through infer_expr.

Fixes #23177

Tests:

• cargo test -p hir-ty
• cargo clippy -p hir-ty --all-targets -- --cap-lints warn
• cargo lint
• cargo test

AI disclosure: AI was used to help investigate and review the change. I wrote the implementation and ran the validation manually.

[ChayimFriedman2]

Per a new rule (that was only merged now but I still want you to abide) in our AI policy:

When using AI to author changes to analysis - the code responsible for analyzing Rust code and not for implementing IDE features, including
but not limited to: type inference, MIR, name resolution, macro expansion - generally anything in the crates parser, mbe, hir-expand, hir-def, hir-ty,
although there are exceptions; including when using AI only to analyze bugs and not to write code, you are required to include a citation
of the rustc code responsible for the change you did, along with an explanation of how your change follows from it in case this is not immediately clear.

The reason for that is that it is almost impossible to be fully correct in analysis if we implement things differently from rustc. We should not guess
how to fix bugs in analysis without looking at the rustc code.

[phpont]

hey, thanks for the heads-up!
just updated the description with the rustc citations and an explanation of how the change follows that behavior.