This seems like an unfortunate case of bean definition overriding where the overriding bean is of a different type than the overridden one, replacing it by name (as per the rules) but not providing a bean reference of the same type, leading to a bean-by-type-not found exception in code which still expects the original bean to be present.
In regular scenarios, an info-level log message "Overriding bean definition for bean..." should be issued. Could you please double-check whether that's present in your scenario? In any case, such overriding for a mix of standalone beans and @Bean-defined beans within configuration classes can be a bit tricky. Let's try to improve this as far as possible, at least providing clearer guidance in case of a type mismatch.