Engine: extract BMS symbolic-map field layouts as a fact channel #3347

Child of roadmap #3249 (epic #3122): the BMS symbolic-map field layouts channel.

What

A BMS map source (DFHMSD / DFHMDI / DFHMDF HLASM macros) defines a CICS 3270 screen: every field's position POS=(line,col), LENGTH, ATTRB, PICIN/PICOUT, INITIAL and OCCURS. Today the engine only counts these statements (ui_framework, args, func_start/class_start), and the refraction differential only sees a map as the cause code bms_symbolic_map when a COBOL program COPYs the symbolic map generated from it. Which fields a screen has, and where, is not in the master DB.

Plan (per gitgalaxy/core/how_to_add_a_fact_channel.md)

• Top-level boundary_extraction: "bms" on the bms definition (never in rules, orphaned_logic reports 100% dead code for five languages whose invocation model never names the callee — the family #2727 closed without covering #2806).
• A bounded extractor that joins HLASM continuation lines (non-blank column 72, resume at column 16, a quoted INITIAL literal continued across lines) and emits a flat mapset → map → field tree (ordinal/parent_ordinal).
• Persist as a per-file child table with FK cascade, restored on delta scans.
• galaxy_ir.EngineFile accessor + SCOPE comment update.
• refraction_differential compared datum against an independent reader in the answer key, plus a drafted answer-key field.
• Tests on real corpus shapes (CBSA bms_src, carddemo app/bms, the crucible's data/bms).

Design call (dedicated table vs a record_data dialect) is recorded in the PR.