Refactor: shared Java-forge helpers, one skeleton-forge pipeline, counters instead of text parsing (before #3618)

[squid-protocol]

Observations (tech debt accumulating across #3613 to #3617).

1. Shared helpers live in the wrong module. The call and repository forges import java_type, _status and _java_field_name from the transaction / spring forges, including private names. Move the shared pieces (type mapping, status text, identifier sanitising, DTO rendering, the extras merge) into cobol_to_java_common.py.
2. Controller orchestration is growing. cobol_to_java_controller.main() now wires three skeleton forges (transaction, call, repository), more are coming (Java conversion: embedded DB2 (table access + DCLGEN) -> repositories, dialect per config #3618 to Java conversion: JCL job flow -> Spring Batch jobs #3622), and features.services / rest_controllers gate them. Introduce one SkeletonForges pipeline object: plan all, write DTOs / entities / clients, hand each service its merged extras.
3. Audit counts parse generated text. The Java conversion: LINK / XCTL / CALL targets (incl. data-driven and remote SYSID) -> service-to-service calls #3616 audit line counts " link" / " call" substrings in generated method lines, which is fragile. Each forge should expose counters (and, with the traceability manifest Java conversion: machine-readable traceability manifest (every generated artifact -> its source facts) #3650, its records).
4. DTO naming. DTOs are named by class-name heuristics in two forges. Centralise the registry so a name collision across forges (a COMMAREA DTO vs an entity key class) is impossible by construction.

Do it before #3618 adds the next forge. Keep behaviour byte-identical: the compile matrix --scan plus snapshot tests guard it.

Part of #3625.

🤖 Generated with Claude Code