TEST: FillBadData AllBadData_TerminatesWithoutHang never reaches the no-progress guard #1848

Summary

The FillBadData test that is meant to cover the "no progress" guard never reaches it. The guard itself may work, but nothing tests it.

What is requested: change SimplnxCore::FillBadData::AllBadData_TerminatesWithoutHang so that it reaches the guard and checks what the guard does. Then correct the V&V report rows that say this test covers it.

Why it is needed: the guard stops the fill loop when bad-data voxels remain but none of them has a good neighbor. Without it, the loop never ends: the hang that this test was written to prevent. Because the test never reaches the guard, a change that breaks the guard would still pass.

How it works now (develop at 2eb6b87):

• The test builds a 3 x 3 x 1 image in which every voxel is bad data (Feature Id 0), and sets Minimum Allowed Defect Size to 1 (line 593).
• Both algorithms keep a bad-data region whose size is at least the threshold as a void, and mark only smaller regions (-1) for filling: FillBadDataBFS.cpp lines 204–222 and FillBadDataCCL.cpp line 441.
• The single 9-voxel region is at least 1, so it is kept as a void. No voxel is marked for filling, and the fill loop has nothing to do. The guard (BFS line 350, CCL line 736) is never reached.
• The test only checks that preflight and execute succeed, so it passes.
• The test comment says "The no-progress guard must return and leave those voxels unchanged." The V&V report says the test covers the guard: path row 16 (vv/FillBadDataFilter.md line 88) and the inventory row (line 106).

This analysis comes from reading the code; no instrumented run was made.

Where it applies: src/Plugins/SimplnxCore/test/FillBadDataTest.cpp and src/Plugins/SimplnxCore/vv/FillBadDataFilter.md (path row 16, the inventory row, and the coverage totals that count row 16).

A threshold larger than the region (for example 100) would mark all 9 voxels for filling with no good neighbor, which is the case the guard handles. The test could then check the warning "… bad-data voxel(s) could not be filled because they have no adjacent good-data neighbor …" and that the voxels are left unfilled, for both algorithm scenarios. Still open: what Feature Id value the unfilled voxels should end with.

Found while reviewing #1829.