"Extract method" refactoring causes the call relationship to change

### Apache NetBeans version

Apache NetBeans 25

### What happened

Refactoring extraction methods leads to changes in code behavior

### Language / Project Type / NetBeans Component

_No response_

### How to reproduce

Select the method to see the output statement in (), select Extract Method Refactoring, the new method name is m, resulting in a change in the calling relationship. Before refactoring, f() calls the method in class A. After refactoring, f() calls the m() method in class B.
Code before refactoring:
```java
class A {
void m(Object m) {
System.out.println("A");
}
}

class B extends A {
void k() {
String s=null;
//extract statements， new method name is ‘m()’
System.out.println(s);
}

void f() {
m("1");
}
}
```
Code after refactoring:
```java
class A {
void m(Object m) {
System.out.println("A");
}
}
class B extends A {
void k() {
String s=null;
//extract statements， new method name is ‘m()’
m(s);
}

private static void m(String s) {
System.out.println(s);
}

void f() {
m("1");
}
}
```

### Did this work correctly in an earlier version?

No / Don't know

### Operating System

window11

### JDK

17

### Apache NetBeans packaging

Apache NetBeans platform

### Anything else

_No response_

### Are you willing to submit a pull request?

No

No source file or test is named. Reproduce the Extract Method refactoring in Apache NetBeans 25 with the Java example and JDK 17, then trace the refactoring behavior around the generated m(String) method. Done means f() still resolves to A.m(Object) after extraction, rather than the new private method in B.

Written by the indexing model from the issue text.