Document behavior when multiple CorsConfigurationSource beans are present

Summary

When multiple CorsConfigurationSource beans are present in the application context,
Spring Security fails to start with an ambiguous bean definition error.

Spring Security does not automatically select one of the available candidates,
but this behavior is currently not clearly documented in the CORS section
of the reference documentation.

This often becomes visible after upgrading to Spring Boot 3 or Spring Framework 6,
but the behavior itself belongs to Spring Security’s CORS integration.

Problem

Given more than one CorsConfigurationSource bean, Spring Security fails with an error like:

Parameter 0 of constructor in org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration
required a single bean, but 2 were found:

corsConfigurationSource

anotherCorsConfigurationSource

From a user’s perspective, this is confusing because:

• A custom CorsConfigurationSource bean is already defined.
• Spring Security does not indicate which bean it expects to use.
• The reference documentation does not mention what happens when multiple such beans are present.

Expected Documentation Behavior

The CORS section of the Spring Security reference documentation should clarify that:

• Spring Security does not automatically choose one CorsConfigurationSource
  when multiple candidates are available.
• Users must explicitly specify which bean should be used.
• This can be done using @Qualifier, @Primary, or the .cors() DSL.

Ideally, this could be documented in the CORS section of the Spring Security reference,
near the examples that show defining a CorsConfigurationSource bean.

Start in the Spring Security reference documentation's CORS section, near the examples that define a CorsConfigurationSource bean. Confirm how multiple candidates are handled and review the documented @Qualifier, @Primary, and .cors() options. Done means the reference clearly explains the ambiguity and how users explicitly select the bean.