[ENH]: don't skip GC for collection in fork tree if using GC v2

[codetheweb]

Description of changes

Does what the title says. Missed this in the original PR.

Test plan

How are these changes tested?

Updated the basic GC v2 E2E test to include a forked collection.

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?

n/a

[propel-code-bot]

Enable GC v2 to Collect Root of Fork Trees for Collections

This PR updates the garbage collector logic to allow garbage collection on the root of fork trees when using GC version 2 (CleanupMode::DryRunV2 or CleanupMode::DeleteV2), whereas previously only GC v1 ran and always skipped such collections. The selection of orchestrator (v1 vs v2) is now determined by a new CleanupMode::is_v2() method, and all fork tree skipping logic is revised to only apply if GC v1 is active; GC v2 collections are now included during collection, with an updated test to cover the new behavior.

Key Changes:
• Introduced CleanupMode::is_v2() helper method to identify v2 modes.
• Refactored orchestrator selection to directly pick v2 implementation if using a v2 cleanup mode.
• Rewrote fork tree root skipping logic: only skip for GC v1, not v2.
• Expanded test to validate GC v2 operates on fork tree roots.
• Adjusted and clarified the logic around cleanup mode lookup in collection loop.

Affected Areas:
• rust/garbage_collector/src/garbage_collector_component.rs
• rust/garbage_collector/src/types.rs
• garbage collection test implementation

This summary was automatically generated by @propel-code-bot

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)