Add Java code graph support and Spring dependency injection resolution

[LudwigAndreas]

What

Added Java code graph support via tree-sitter-java.wasm and production-ready Spring dependency injection resolution.

This includes:

• Java extraction for annotations, imports, inheritance, field/parameter/return type references, method calls, object instantiations, and decorator relationships.
• Spring framework resolver supporting component scanning, constructor injection, @Bean providers, qualifiers, @Primary, and Lombok-generated constructor injection.
• Registration of the Spring framework resolver.
• Java/Spring fixtures, integration tests, and documentation updates.

Why

This enables MEX to build accurate code graphs for Java projects and resolve Spring dependency injection relationships that are implicit in source code. As a result, navigation and dependency analysis now include both static Java references and framework-managed bean dependencies.

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• CI/Tooling

How to test

1. Run mex check on a Spring-based Java project.

2. Verify the generated graph includes:

   • Java symbol relationships (imports, inheritance, type references, calls, and instantiations).
   • Spring dependency edges between injected beans (including constructor injection and @Bean providers).

3. Run:

   npm test
   npm run typecheck
   npm run build

Checklist

• Tests pass (npm test)
• No breaking changes
• Tested locally with a real project

Code-graph changes

• This PR targets main
• A linked issue agrees on the bounded extractor/resolver scope
• The change follows the frozen LanguageExtractor or FrameworkResolver interface
• A focused fixture and assertions for the expected node/edge shape are included
• Any new grammar WASM, extension mapping, extractor, or resolver is registered
• No graph identity, reconciliation, schema, or drift-semantics changes are included, or a core / discuss-first issue is linked above

[theDakshJaitly]

The focused Java/Spring tests, typecheck, and build pass, but the implementation currently corrupts common Java symbol identities and can create incorrect Spring DI edges. Please address the inline findings. In addition, this cannot be approved under the documented code-graph contribution policy as submitted: no approved code-graph issue is linked, and docs/extractors.md explicitly requires the language extractor to merge before its framework resolver rather than bundling both in one PR. Please split the Java extractor and Spring resolver into separately scoped changes backed by an approved issue.

[theDakshJaitly]

Using only the simple declaration name here produces duplicate IDs for ordinary Java code. The supplied fixture emits 27 nodes but only 25 unique IDs: PaymentGateway.charge() collides with StripePaymentGateway.charge(), and the inventory fields in OrderService and ReportService also collide. GraphStore.insertNode upserts on ID, so later declarations overwrite earlier ones and containment edges point at the same persisted symbol. Please derive a stable scope-qualified identity for Java declarations (and keep the Spring resolver's generated source IDs aligned), with tests covering same-named members in different classes and overloaded methods.

[theDakshJaitly]

This fallback runs even when an explicit qualifier failed to match. Replacing @Qualifier("stripe") with @Qualifier("missing") still resolves the dependency to the unique PaymentGateway interface at 0.75 confidence, creating a wrong DI edge instead of leaving it unresolved. When a qualifier is present and no bean with that name matches, please return null; add coverage for unknown qualifiers and ambiguous candidates.

[theDakshJaitly]

This repository-wide agent configuration is unrelated to Java/Spring graph support and still contains placeholders such as [Project Name] and empty command/non-negotiable sections. Because root AGENTS.md changes instructions for every coding agent working in the repository, please remove this file from the PR.