ENH: FillBadData out-of-core optimization

[imikejackson]

Used Claude-Code (Sonnet 4.5) to reimplement this filter's algorithm to better optimize for out-of-core performance without hugely impacting the in-core performance.

Both out-of-core builds and in-core builds pass the same unit test indicating that for the given input data set we are producing the same results. This code should be actually verified with smaller, more concise data sets to completely validate the algorithm is producing what we expect it to produce.

Claude-Code generated more unit test files that better exercise the edge cases of the algorithm. The Small IN100 test case exercises the out-of-core performance.

[nyoungbq]

Approving, suggestion is mostly for the sake of cleanup. The Union-Find structure looks to be all good. From the few times I have used Union-Find, I am not sure whether compressing the paths should be done at every merge. If your doing frequent merges you are wasting cycles updating values that will be updated again if it gets merged again, rather than one pass through at flatten for future searches. I understand it cuts down the depths of the trees though, so perhaps that provides an optimization when searching the trees during construction. Also worth noting the types sometimes use our type declarations uint64 and others use the standard uint64_t, I would bring them all in line one way or the other. The rest looks good as far as I can tell.