fix: detect unsafe module references in H5 nested config objects

[scruge1]

Summary

H5LambdaDetectScan only inspected top-level layers for class_name == "Lambda". Any module/class_name reference nested elsewhere in the H5 model_config tree (initializers, regularizers, constraints, dtype policies, custom layers) was ignored, so a non-Keras module such as builtins.exec hidden in a kernel_initializer was reported as 0 issues — a false negative — even though Keras resolves that module via importlib when the model is loaded with tf.keras.models.load_model(..., safe_mode=False).

This recurses the full model_config tree and flags every module reference outside the keras/tensorflow/tf_keras namespace as an unsafe operator. It mirrors the equivalent .keras-format fix (#340) for the H5 path; the two scanners use independent operator-extraction methods, so the H5 path needed its own patch.

Why

The file is scanned (not skipped) yet returns no issues for a payload that executes on load — a true false negative in the model-file scanner.

Testing

Adds tests/test_h5_nested_config.py:

• test_h5_nested_unsafe_module_detected — a nested builtins.exec kernel_initializer is now flagged as an unsafe operator (previously 0 issues).
• test_h5_benign_keras_module_not_flagged — a standard keras.initializers.GlorotUniform reference is not flagged (no false positive).

Both pass locally (Python 3.10, h5py 3.14, tensorflow 2.21).

Checklist

• Tests added and passing locally
• No exploit code included
• DCO sign-off