Incremental processing misses changes in Java classes from the classpath

If a processor resolves into a Java class that comes from the compilation classpath, and that class later changes, KSP does not reprocess the sources that depend on it, so the generated output goes stale. A non-incremental run (`--rerun`) produces the correct output. With Kotlin classpath declarations everything works, KAPT is also fine.

Looks like the Java counterpart of #3011.

**Steps to reproduce**

Two modules: `upstream` (Java library) and `downstream` (Kotlin, applies KSP). While processing a `downstream` source, the processor resolves into an `upstream` class and generates code based on it.

1. Build `downstream`.
2. Make an ABI change to the `upstream` class.
3. Build again, incrementally.

The KSP task runs (it is not `UP-TO-DATE`), but skips the dependent file and the output stays unchanged.

**Real-world impact**

We hit this with [Yatagan](https://github.com/yandex/yatagan), a Dagger-like DI framework. A Java library module declares a binding:

```java
// upstream module (Java)
@Module
public interface FooModule {
@Binds
Foo foo(FooImpl impl);
}
```

The component that includes this module lives in another Gradle module and is processed by KSP there. Switching the binding to another implementation:

```java
@Binds
Foo foo(BarFoo impl);
```

and rebuilding incrementally does not regenerate the component: it keeps instantiating `FooImpl`. In other setups the same scenario ends with a compilation error, because the generated code references classes that no longer match the module. Only a clean/`--rerun` build picks the change up.

**Environment**

KSP 2.3.11, Kotlin 2.4.10.