dagmenu _get_switch_node_attrs matches string attributes as space-switch attrs

[BramVR]

Description

_get_switch_node_attrs() in dagmenu.py matches any keyable user-defined attribute whose name ends with a given suffix (e.g. "ref", "follow"), but does not check the attribute type. String attributes like guide_loc_ref match the "ref" suffix and are returned as space-switch attributes.

Impact

1. False positive matching: guide_loc_ref (a string attribute with value "root") is treated as a space-switch enum, causing incorrect ui_host determination and bogus menu items.

2. NoneType crash: When the false-positive string attribute reaches the space-switch menu builder, cmds.addAttr(query=True, enumName=True) returns None for a non-enum attribute. The code calls .split(":") directly on the result, raising AttributeError: 'NoneType' object has no attribute 'split'.

Steps to Reproduce

1. Have a control with a string attribute ending in "ref" (e.g. guide_loc_ref) but no real space-switch enum attributes
2. Right-click on that control
3. The dagmenu either shows incorrect space-switch items or crashes with an AttributeError

Note: In practice this is currently masked by the cmds.controller segfault (#XXX) which crashes Maya before this code is reached.

Proposed Fix

1. Add an attribute type check in _get_switch_node_attrs to skip attributes of type "string" or "typed", since space-switch attributes are always enum or numeric.
2. Add a null guard on the enumName query result before calling .split(":").

[BramVR]

Hi Miguel, thanks for checking!

Yes, it is Maya 2025.3. The 202409190603 is the build compilation date (September 2024), not the Maya version.

The crash for us happened specifically on controls high in the controller tag hierarchy (body, spine) where the traversal expands to 50-70+ descendant tags. Controls lower in the hierarchy (arms, fingers) worked fine. If you want to try reproducing, a rig with a deep/wide controller tag hierarchy would be the one to test with.