fix(java-enum): resolve enum methods from enum_body_declarations

[sahil-mangla]

What does this PR do?

Resolves extraction and calling-edge issues for Java enums that define methods (e.g., isWeekend or label in cp_enum_method_java).

In tree-sitter-java, an enum's methods are declared within an enum_body_declarations block, which is a nested child of enum_body rather than a direct child of the enum declaration itself. Previously:

• find_class_body resolved only the raw enum_body node.
• extract_class_methods iterated over this body, encountering constants and separator tokens, but missing the nested enum_body_declarations block. As a result, method definitions were ignored and calling edges failed to resolve.

This change:

1. Updates find_class_body to correctly scan and inspect the enum_body for nested enum_body_declarations nodes and return them.
2. Adds enum_body and enum_body_declarations to the list of recognized body containers in push_class_body_children so the AST traverser pushes all method declarations under the correct enum QN namespace.
3. Complies with the 100-character column format limit in extract_defs.c.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[DeusData]

Thanks. I have triaged this as a 0.9.1-rc Java extraction bug fix. Review should verify that enum_body_declarations handling fixes enum methods without changing normal class/interface method extraction or introducing duplicate method definitions.

[DeusData]

Thanks for splitting this out of #893 so quickly — exactly the atomic shape we asked for, and the enum_body_declarations analysis matches tree-sitter-java's grammar. One thing missing before merge: a genuine reproduce-first guard. I ran the existing cp_enum_method_java convergence probe on unmodified main and it already PASSES — its assertions (Enum node exists + ≥1 CALLS edge anywhere) are too loose to detect the bug you're fixing, so nothing in CI currently turns red without your change. Please add an extraction-level test that is RED on main and GREEN with this fix — e.g. in tests/test_extraction.c, extract the Day enum fixture and assert isWeekend/label exist as Method definitions (and/or tighten the probe to assert the enum's methods specifically). With that guard in place this merges immediately.

[DeusData]

Thanks for this, @sahil-mangla — the Java enum-method extraction fix is genuinely good work, and the java_enum_method test is a proper reproduce-first guard (it fails on main without the enum_body_declarations unwrap). I'd happily merge that part quickly.

One blocker before it can land: the PR also carries an undocumented change to the call-resolution core — src/pipeline/registry.c (+127/−22), restricting resolve_same_module/resolve_name_lookup on receivers (commits e930bd2 + 078de1c). That's a precision-tightening change to CALLS-edge resolution with all-language blast radius, and it's not mentioned in the PR description. Per our atomic-PR policy it needs to be its own PR so its recall-vs-precision impact can be evaluated on the full corpus independently of the enum fix.

Could you split this into two PRs?

1. The Java enum fix — extract_defs.c (enum_body/enum_body_declarations unwrap + enum-name fallback) + tests/test_extraction.c. This is clean and I'll fast-track it.
2. The registry resolution-tightening — registry.c + tests/test_registry.c, with a note on what false positive it targets (looks recursion-related) so we can measure edge impact before merging.

Really appreciate the contribution — just want each change reviewable on its own merits.

[sahil-mangla]

@DeusData as per requested the PRs are now strictly atomic! with registry fix being its own isolated PR at #1128