[Bug] The dynamic configuration updates at the application-level are not effective immediately (or in real-time) for application-level calls in Dubbo 3

### 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 SDK (apache/dubbo)

### Dubbo Version

Dubbo Java 3.2.11，jdk 1.8，mac os 14.2

### Steps to reproduce this issue

1.First, define and deploy the provider of the RPC interface com.demo.framework.dubbo.demo.api.UdubboDemoService

2.Use the FORCE_APPLICATION invocation strategy

dubbo.application.migration.step=FORCE_APPLICATION

3.Start the subscriber application to invoke the provider, and observe the old timeout and retry value

4.Then modify the subscriber’s application-level dynamic configuration for timeout and retries

5.Observe whether the dynamic configuration takes effect

### What you expected to happen

The expected values for the timeout and retry configurations in the actual invocation should be consistent with the application-level dynamic configuration, but the settings did not take effect, and the old timeout and retry values were retained.

### Anything else

I have identified the potential cause. The issue might be in the following code:

In the ServiceDiscoveryRegistryDirectory class, the return value of the urlChanged method does not reflect changes in the application-level dynamic configuration. Consequently, the invoker is not re-initialized, and the system continues to use the old invoker, which is why the dynamic configuration is not taking effect in real-time. In contrast, dynamic configurations at the service/interface level are taking effect in real-time.

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

- [x] 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 ServiceDiscoveryRegistryDirectory.urlChanged and trace how application-level dynamic configuration changes reach the invoker when FORCE_APPLICATION is enabled. Reproduce the reported timeout and retry update after deployment, then verify that application-level changes trigger the same effective refresh behavior as service-level changes and that subsequent calls use the new values.

Written by the indexing model from the issue text.