bms falls through to Mode_B_Braces: functions_found 0 on the rosetta shell (13 raw DFHMDI matches, none reach function_data) #3077

Found by the keyword-rosetta bias report the day #2505/#3074 landed: bms's extraction layer is exact (verify_language.py PASS, 100 assertions) but functions_found = 0 against a corpus median of 13, which drags six per-function descriptors (avg_func_*, max_func_complexity, func_complexity_gini, func_internal_density) to undefined and units_public/units_documented to 0.

Root cause — the exact #1899 (abap) / #1974 (dockerfile) / #1975 (jcl, m4) shape, again: bms has no ScopeParsingRegistry entry and no braces (HLASM macro source; a { can only occur inside an INITIAL='...' literal), so _route_and_slice falls through to Mode_B_Braces, which finds nothing. The func_start rule itself fires correctly (13 raw matches on the rosetta shell).

Fix — route bms through Mode A ("greedy to the next func_start match"): maps never nest, so each named DFHMDI's body genuinely runs to the next DFHMDI/DFHMSD statement or EOF. Also add bms to _CLASS_START_NAMED_EXTRACTION_LANGS so the DFHMSD mapset name extracts as the named class (the generic class|struct|... fallback can never match HLASM).

Cross-repo: after this merges, keyword-rosetta needs a rebless (units_public cells move from 0 once the maps exist as units; functions_found 13 restores the per-function rows) — will be opened as the paired corpus PR per docs/GATING.md's cross-repo flow.

🤖 Generated with Claude Code