[Bug] Dubbo 2.7.23 Consumer not consuming properly when provider custom extends Dispatcher

### Pre-check

- [X] I am sure that all the content I provide is in English.

### Search before asking

- [X] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar issues.

### Apache Dubbo Component

Java SPI Extensions (apache/dubbo-spi-extensions)

### Dubbo Version

Dubbo Java 2.7.23,openJdk 1.11

### Steps to reproduce this issue

1 CustomDispatcher implements Dispatcher and implements the related methods.
2 In the META-INF/dubbo directory, create a new file with the name org.apache.dubbo.remote.Dispatcher, with the content custom=com.xx.xx.CustomDispatcher
3 Call ProtocolConfig's setDispatcher method to set it to custom: protocolConfig.setDispatcher("custom")
4 start Provider sucessfully
5 When starting the consumer, it encounters the no provider error, and when tracing it through the debug, I found that when creating the NettyClient object, it calls org.apache.dubbo.remote.transport.dispatcher.ChannelHandlers#. wrapInternal -> ExtensionLoader.getExtensionLoader(Dispatcher.class)
.getAdaptiveExtension() can't find the class CustomDispatcher and gives error
PS: This error is not encountered when the Dispatcher's implementation class is changed to the built-in configuration.

### What you expected to happen

The client-side Dispatcher should not be bound strictly and consistently to the server-side. If this is the case, there is no way to optimise the server-side Dispatcher schema when the client-side code is unable to make a task change that needs to be done

### Anything else

_No response_

### Are you willing to submit a pull request to fix on your own?

- [ ] Yes I am willing to submit a pull request on my own!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Start with org.apache.dubbo.remote.transport.dispatcher.ChannelHandlers.wrapInternal and the Dispatcher SPI file under META-INF/dubbo, then reproduce the issue using a custom Dispatcher and ProtocolConfig.setDispatcher("custom"). Check the consumer startup path around ExtensionLoader.getAdaptiveExtension(). Done means a provider using the custom Dispatcher can start while the consumer no longer fails with a no-provider error because it cannot load that implementation.

Written by the indexing model from the issue text.