Protect erase_resource and set_resource_health against cyclic sub-resources

[ZayanKhan-12]

Closes #403

Problem

As reported in #403, nmos::erase_resource recurses into sub_resources before the resource itself is marked erased, so a resource that is (directly or indirectly) listed as a sub-resource of itself causes unbounded recursion and a stack overflow.

While writing the regression test, it turned out set_resource_health has the same defect — and it is actually hit first: insert_resource calls it to propagate health, so merely inserting a resource whose cyclic relationship already exists in the registry crashes before any erase happens.

Fix

Both functions now delegate to internal helpers that track the ids already visited during the recursive descent and skip any id seen before. Per the discussion in #403, this handles not just self-reference but cycles of any length (A→B→A etc.). Public signatures, event order, and results for well-formed sub-resource trees are unchanged.

Testing

New nmos/test/resources_test.cpp:

• self-referencing resource: insert + erase completes, count 1 (previously stack overflow — first in set_resource_health via insert_resource, then in erase_resource)
• mutual A↔B cycle: erase of A erases both, count 2
• sanity: normal parent/child tree still erases exactly the resource and its sub-resources

Full local suite: all 170 test cases / 2349 assertions pass (macOS arm64, apple-clang, conan dependencies).

🤖 Generated with Claude Code

[garethsb]

As pointed out in #403, a sub-resource cycle is an application bug, therefore further discussion needed to decide whether to accept this workaround which hides the actual problem as-is or to modify it to throw a logic_error which the application developer must handle.

I'm not sure if it's possible to detect the insertion or modification of resources that introduce sub-resource cycles. That would be useful.

[garethsb]

On reflection, I think adding this cost to every erase and health check is the wrong approach, better to prevent the obvious ways an application could have got itself into that state (trying to insert a resource with the same id as one of its ancestors). I propose #516.