Autoharness: reject an instantiation whose invalid SIMD intrinsic call is one level down #4926

Follow-up to #4919.

That fix has autoharness reject a candidate type when the function's own body would call a SIMD intrinsic with a non-SIMD operand, so the reported reproducer (and core_arch::simd::simd_imin) now picks a SIMD type or is skipped with a specific reason.

It only inspects the candidate function's own body, though. A generic function that reaches the invalid instantiation through a call is not detected:

pub unsafe fn imin<T: Copy>(a: T, b: T) -> T {
    let mask: T = simd_lt(a, b);
    simd_xor(mask, b)
}

// Its own body calls no SIMD intrinsic, so `T = i32` is chosen.
pub unsafe fn calls_imin<T: Copy>(a: T, b: T) -> T {
    imin(a, b)
}

Codegen catches it, so the run no longer aborts, but the harness for calls_imin::<i32> fails with an unsupported construct for a monomorphization rustc would reject — a harness that can never correspond to real code. tests/script-based-pre/autoharness_simd_non_simd_instantiation pins the current behavior, so a fix should update that test's expectations.

Detecting it means following calls outward from the candidate, as has_const_generic_precondition does for const-block preconditions (#4794), and composing the substitutions along the chain so the deeper intrinsic's operand type can be resolved for the candidate under consideration. The const-block search sidesteps composition by being conservative; being conservative here would skip generic callers of SIMD helpers that are fine, so it likely wants the precise version.

Lower priority than #4919: the run completes either way, and this only affects the accuracy of one harness's reported result.