Documentation wording about multiple SecurityFilterChains and RequestMatcher ordering is misleading

[meqbyte]

Describe the bug
The documentation describing how multiple SecurityFilterChains are matched can be misleading. ref

The following wording suggests a runtime fallback mechanism based on ordering:

If a request does not match a SecurityFilterChain with higher priority (e.g. @order(1)), the request can be tried against a filter chain with lower priority (e.g. no @order).

This can be interpreted as allowing multiple SecurityFilterChains with identical RequestMatchers differentiated only by @order.

But, in spring security 6.4,identical matchers across multiple chains are not allowed and cause startup-time validation failures