The UndertowJSRWebSocketDeploymentProcessor looks for types annotated with both @ServerEndpoint and @ClientEndpoint. Per the Jakarta WebSocket 2.2 specification on section 6.2:

The Jakarta WebSocket implementation must use the web container scanning mechanism defined in Servlet 3.0 to find annotated and programmatic endpoints contained within the WAR file at deployment time [WSC-6.2-1]. This is done by scanning for classes annotated with @ServerEndpoint and classes that extend Endpoint. See also Section 4.8 for potential extra steps needed after the scan for annotated endpoints. Further, the WebSocket implementation must use the WebSocket scanning mechanism to find implementations of the ServerApplicationConfig interface packaged within the WAR file (or in any of its sub-JAR files) [WSC-6.2-2].

There is a TCK challenge that is likely to get rejected.

We made an attempt to fix this in WFLY-21218. That fix simply stopped invalid clients from being scanned. The TCK, IMO, has a deployment packaging error that is still causing failures. However, we don't need to scan for these client endpoints so we should likely just stop.