fix(workflows): route detections_consensus IoU through detection geometry

[kounelisagis]

What does this PR do?

DetectionsConsensusBlockV1.calculate_iou always uses sv.box_iou_batch on xyxy, regardless of what geometry each detection actually carries. For instance-segmentation or OBB workflows that's the bounding box of the actual shape - which can overlap heavily even when the masks / oriented bodies don't. Two detections with identical AABBs but disjoint masks (or crossed OBBs in an aerial image) end up matched as the same object, and consensus silently merges them.

The fix dispatches on the geometry the detections actually carry:

• mask_iou_batch when both have a mask
• oriented_box_iou_batch when both have data["xyxyxyxy"]
• box_iou_batch otherwise (unchanged)

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Testing

• I have tested this change locally
• I have added/updated tests for this change

Test details:

Two new unit tests in tests/workflows/unit_tests/core_steps/fusion/test_detections_consensus.py:

• test_calculate_iou_uses_mask_iou_when_both_have_masks - identical AABB, disjoint masks -> IoU 0.0 (would be 1.0 pre-fix).
• test_calculate_iou_uses_obb_iou_when_both_have_oriented_boxes - crossed OBBs at +-45°, near-identical AABBs -> IoU < 0.2 (would be > 0.95 pre-fix).

Both fail on main. Existing calculate_iou tests are unchanged.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in hard-to-understand areas
• My changes generate no new warnings or errors
• I have updated the documentation accordingly (if applicable)

Additional Context

The block already accepts a detections_merge_mask_aggregation parameter and is wired up to instance-segmentation models, so mask support was clearly intended - but the matching step itself was still bbox-only, so the aggregation never actually saw masks that the user expected to be merged.