filter is applied to paths that should be allowed in http security configuration with new SS 6.4.3

Describe the bug
this is how I configure http security using the SS 6.4.3

  @Bean
  open fun securityFilterChain(http: HttpSecurity, authManager: AuthenticationManager): SecurityFilterChain {
    http {
      authorizeHttpRequests {
        authorize(HttpMethod.OPTIONS, "/**", permitAll)
         authorize(HttpMethod.GET, "/swagger-ui.html", permitAll)       
        authorize(anyRequest, authenticated)
      }
      csrf { disable() }
      sessionManagement {
        sessionCreationPolicy = SessionCreationPolicy.STATELESS
      }
      addFilterBefore<AuthorizationFilter>(MyFilter(processor, authManager))
    }
    return http.build()
  }

even though '/swagger-ui.html' is configured to skip authentication, MyFilter is found applied to /swagger-ui.html. It was not the case with SS 5.4

if I enable debug in security config, here is the list of filters applied to '/swagger-ui/*'

servletPath:/swagger-ui/swagger-ui.css
pathInfo:null
headers:
host: localhost:8090
connection: keep-alive
sec-ch-ua-platform: "macOS"
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
sec-ch-ua: "Chromium";v="134", "Not:A-Brand";v="24", "Google Chrome";v="134"
sec-ch-ua-mobile: ?0
accept: /
sec-fetch-site: same-origin
sec-fetch-mode: cors
sec-fetch-dest: empty
referer: http://localhost:8090/
accept-encoding: gzip, deflate, br, zstd
accept-language: en-US,en;q=0.9

Security filter chain: [
DisableEncodeUrlFilter
WebAsyncManagerIntegrationFilter
SecurityContextHolderFilter
HeaderWriterFilter
LogoutFilter
MyFilter
RequestCacheAwareFilter
SecurityContextHolderAwareRequestFilter
AnonymousAuthenticationFilter
SessionManagementFilter
ExceptionTranslationFilter
AuthorizationFilter
]

To Reproduce
Steps to reproduce the behavior.

Expected behavior
filter added later should NOT be applied to paths configured with permitAll

Sample

A link to a GitHub repository with a minimal, reproducible sample.

Reports that include a sample will take priority over reports that do not.
At times, we may require a sample, so it is good to try and include a sample up front.

Start with the provided SecurityFilterChain configuration, focusing on authorizeHttpRequests, addFilterBefore, and the custom MyFilter. Reproduce requests to /swagger-ui.html and /swagger-ui/* with Spring Security 6.4.3 and compare the listed filter chains with the expected permitAll behavior. Done means the later-added filter is not applied to paths configured with permitAll.