codeanalyzer-java: carry CRUD enrichment into schema v2

[sinha108]

Plan (optional)

Design spec: https://github.com/codellm-devkit/codeanalyzer-java/blob/main/docs/design/specs/schema-v2-l3-l4-design.md

Problem

The v1 analyzer emits CRUD enrichment — crud_operations / crud_queries on callables and per-call-site CRUD data, produced by CRUDFinderFactory (src/main/java/com/ibm/cldk/javaee/) — and the Neo4j projection declares JCrudOperation / JCrudQuery node families with J_HAS_CRUD_OPERATION / J_HAS_CRUD_QUERY relationships. The schema-v2 migration (epic #42) did not account for carrying this into v2: the v2 L1 tree (#180) emits no CRUD data, so v2 output currently regresses against v1 for every CRUD consumer, and #182 (Neo4j v2 relabel) has no v2 CRUD families to relabel.

Entrypoint detection (is_entrypoint / is_entrypoint_class) is handled in #180 — it is a cheap syntactic predicate over declarations. CRUD is separated here because it is materially different (see below).

Scope boundary

CRUD enrichment only. Entrypoint flags are #180. This issue does not add new CRUD detection capability (that is #112, JDBC support) — it carries the existing finders' output into the v2 shape and its Neo4j projection.

Goals

• Decide and record the v2 CRUD schema shape in .claude/SCHEMA_DECISIONS.md — the canonical keystone has no CRUD vocabulary, so this is an explicit Java-specific extension (per the keystone's language-expansion rubric: new typed field vs open-vocab tags)
• Make the receiver type available to the finders in the L1/L2 builder context — CRUD keys on the resolved declaring type, whereas the v2 L1 builders are deliberately syntactic today (L1BuildContext has no symbol solver)
• Attach CRUD data to body call nodes (and/or aggregate on the callable), including the argument expressions the query finders need
• Project JCrudOperation / JCrudQuery + J_HAS_CRUD_OPERATION / J_HAS_CRUD_QUERY in the Neo4j v2 catalog (coordinate with codeanalyzer-java: Neo4j v2 base relabel #182)
• Reconcile the richer Neo4j-declared CRUD props (target_table, involved_columns, condition, joined_tables) with what the JSON model actually carries — either populate or drop them
• Consider moving framework/CRUD enrichment onto the pluggable pass layer (analysis/ registry + frameworks/ finder base) per the analyzer-architecture guidance that domain concerns must not reshape the structural module/type/callable/call nodes

Caveats and known risks

• Requires symbol resolution in a builder layer that is otherwise syntactic; resolution failures must degrade gracefully (never crash, never block L1).
• The keystone has no CRUD vocabulary — this is an additive language extension and must not rename or repurpose shared names (parity clause).
• v1's CRUD detection is heuristic (receiver-type + method-name matching); carrying it over preserves its known imprecision. Document, do not silently absorb.

Definition of done

• v2 output carries the same CRUD facts v1 did for the fixture apps (a named expected CRUD operation and query asserted, not just "non-empty").
• The v2 CRUD shape is recorded in .claude/SCHEMA_DECISIONS.md.
• Neo4j projection emits the CRUD families with no dangling relationships; cross-projection counts agree.
• Output validates against the v2 models; the L1 ⊆ L2 superset gate still holds.