Java conversion: PL/I programs through the same pipeline

[squid-protocol]

PL/I programs (call sites, units of work, data moves, DECLARE structures) get the same generation as COBOL.

Part of the COBOL→Java conversion epic.

🤖 Generated with Claude Code

[squid-protocol]

Done. PL/I now goes through the same COBOL→Java pipeline as COBOL.

• Part 1 (PR feat(cobol-to-java): PL/I programs through the pipeline (#3623, part 1) #3721): PL/I programs are recognised by their MAIN / FETCHABLE procedure and named after their member. Each gets an engine-built IR dump and a verified skeleton, and a service with its CICS LINK, TS queues and SYNCPOINT wired from the facts. The whole DSF estate (431 programs) compiles.
• Part 2 (PL/I record layouts: storage widths, the main-procedure COMMAREA, DTOs (#3623 part 2) #3720, PR PL/I record layouts, the PL/I COMMAREA and typed DTOs (#3720) #3729): PL/I record layouts follow IBM's structure-mapping rules, reproducing the Language Reference's worked example exactly. The COMMAREA is read from the structure BASED on the main procedure's pointer parameter (CICS programs only), and DTO fields get proper PL/I→Java types. It fixed a CALL-contract sizing defect (D026).
• Answer key and census (PL/I record layouts: answer-key field + census (#3720 part 3) #3727, PR PL/I record layouts: answer key + blind census (#3727) #3733): a blind census of PL/I layouts (DSF 309/309 sampled, zopeneditor 27/27 in full). The engine matches the key on every unit. The key also exposed an ALIGNED bit-string gap, which is fixed.
• %INCLUDE inside a DECLARE (PL/I: %INCLUDE inside a DECLARE is not expanded into the structure #3728, PR PL/I: an %INCLUDE inside a DECLARE is spliced in, or the layout is unknown (#3728) #3737): a structure whose members come from an include is spliced from the member, or reported as unknown with the member named, never silently truncated (D027).