Suggest qualifying struct literal path to "escape the shadow" cast by struct-like enum variant

Given

#![feature(more_qualified_paths)]

enum E { S { gotten: () } }
struct S { wanted: i32 }

trait O { type S; fn f(); }
impl O for E {
    type S = S;
    fn f() { // (A)
        let _ = Self::S { wanted: 0 }; //~ ERROR variant `E::S` has no field named `wanted`
    }
}

fn main() { // (B)
    let _ = E::S { wanted: 0 }; //~ ERROR variant `E::S` has no field named `wanted`
}

Self::S (A) / E::S (B) resolves to the enum variant, not the associated type and thus

error[E0559]: variant `E::S` has no field named `wanted`
  --> src/main.rs:10:27
   |
10 |         let _ = Self::S { wanted: 0 };
   |                           ^^^^^^ `E::S` does not have this field
   |
   = note: available fields are: `gotten`

error[E0559]: variant `E::S` has no field named `wanted`
  --> src/main.rs:15:20
   |
15 |     let _ = E::S { wanted: 0 };
   |                    ^^^^^^ `E::S` does not have this field
   |
   = note: available fields are: `gotten`

Ideally, since (and only since) more_qualified_paths is enabled, rustc would suggest qualifying Self::S and E::S via <Self as O>::S and <E as O>::S, respectively.

These might be quite annoying to diagnose due to the sheer number of possible symptoms (e.g., missing fields, extra fields, fields of wrong type). Since this input is a bit contrived, marking P-low.

Case (A) is reminiscent of #57644 but still distinct (however, do we want to do anything here?).

Reproduce the provided Rust snippet with the more_qualified_paths feature enabled and inspect both E0559 diagnostics at locations (A) and (B). Determine whether the compiler can suggest qualified associated-type paths for these cases, then add diagnostic coverage showing the expected suggestions and behavior for the reported field-error variants.