fix(feature_chainer): a hostile in_features value raises out of match_feature_group_criteria

[TKaltofen]

Summary

FeatureChainParserMixin._validate_in_features calls options.get_in_features() without guarding it, so an option value it cannot convert raises out of match_feature_group_criteria and aborts feature resolution instead of making that candidate a non-match.

Reproduction

Any FeatureGroup using the mixin with MIN_IN_FEATURES / MAX_IN_FEATURES set, matched against Options carrying a hostile in_features:

SomeFeatureGroup.match_feature_group_criteria("my_result", Options(context={"in_features": "", ...}), None)
# ValueError: Input features not found in options...
SomeFeatureGroup.match_feature_group_criteria("my_result", Options(context={"in_features": {"a": 1}}), None)
# TypeError: Unsupported type for source feature: ...

identify_feature_group.py calls the matcher with no try/except, so one bad option value on one candidate fails the whole resolution rather than skipping that candidate. Every other rejection path in the mixin returns False: match_guard catches TypeError / ValueError / AttributeError, and a strict-validation ValueError is caught around match_configuration_feature_chain_parser.

Downstream this was worked around in mloda-registry by declaring a match_guard on the in_features entry of three feature groups (mloda-ai/mloda-registry#330), which only helps the groups that remember to declare it.

Code pointers

• mloda/core/abstract_plugins/components/feature_chainer/feature_chain_parser_mixin.py, _validate_in_features (the len(options.get_in_features()) call)
• mloda/core/prepare/identify_feature_group.py (the unguarded matcher call)

Definition of done

• An in_features value that cannot be resolved makes the candidate a non-match, consistent with the other rejection paths
• The rejection is logged at debug level with the offending value, like match_guard failures
• Tests cover "", 0, a float, a bool and a dict