mGCA: Syntactic type mismatch diagnostic can leak `{type error}` for forbidden inferred types `_` in the type of type-level const items

[fmease]

With syntactic type mismatch I'm referring to mismatches detected by the pre-normalization check in HIR ty lowering for tuples & non-repeat arrays (as contrasted with the semantic ConstArgHasType check used for other expr kinds).

Reproducers:

#![feature(min_generic_const_args)]
#![expect(incomplete_features)]

type const T0: _ = ();

error[E0121]: the placeholder `_` is not allowed within types on item signatures for constants
 --> file.rs:4:16
  |
4 | type const T0: _ = ();
  |                ^ not allowed in type signatures

error: expected `{type error}`, found const tuple
 --> file.rs:4:20
  |
4 | type const T0: _ = ();
  |                    ^^

#![feature(min_generic_const_args)]
#![expect(incomplete_features)]

type const T1 = [0];

error: missing type for `const` item
 --> file.rs:4:14
  |
4 | type const T1 = [0];
  |              ^
  |
help: provide a type for the item
  |
4 | type const T1: <type> = [0];
  |              ++++++++

error: expected `{type error}`, found const array
 --> file.rs:4:17
  |
4 | type const T1 = [0];
  |                 ^^^

[fmease]

{type error} should ideally not leak into diagnostics, in both cases the 2nd diagnostic shouldn't be reported at all. Currently, the respective checks match on the TyKind but don't account for TyKind::Error(guar).

[Human9000-bit]

@rustbot claim