fix(spring): scope DI resolver to Java/Kotlin and skip extends/implements references

[htarnacki]

Fixes #1825

Problem

Once Spring is detected (a single sibling Java module with spring-boot in its pom.xml is enough in a polyglot repo), springResolver.resolve() evaluated every unresolved reference regardless of language or reference kind. Pattern 4 (Entity/Model) matches any bare capitalized name and falls back to any same-named class in the graph, so Scala extends X references were hijacked to unrelated Java classes (in practice: test fixtures under /test/.../model/) with resolvedBy: 'framework', bypassing import/name matching.

Changes

• frameworks/java.ts: two gates in front of the DI/convention patterns (1–5), leaving the Spring config-key resolution above them untouched (it already checks language):

  if (ref.language !== 'java' && ref.language !== 'kotlin') return null;
  if (ref.referenceKind === 'extends' || ref.referenceKind === 'implements') return null;

  Spring DI conventions do not apply to non-Java/Kotlin code, and inheritance is never a DI point — extends/implements must resolve via imports/name matching in every language.
• Tests (frameworks.test.ts): Scala extends ref and Scala plain ref do not resolve through the Spring resolver; Java extends ref does not either; a Java DI reference still resolves through Pattern 4.
• CHANGELOG: entry under [Unreleased].

Verification

On a production Scala codebase with sibling Java modules (~900k nodes), Scala extends/implements edges resolved by the framework resolver dropped from 5894 to 633 — the remaining ones are legitimate Java/Kotlin resolutions. Combined with #1824, codegraph impact on a widely-mixed-in trait went from 28 to 186 affected symbols.

Full test suite run with Node 24 (FTS5): green (one timing-sensitive test, sync-rebuild-convergence, is flaky under load on main as well and passes in isolation).