sort

[SFJohnson24]

this PR does a few things:

• adds sort logic to distinct and dataset_names
• updates their tests

also in running https://github.com/cdisc-org/cdisc-open-rules/actions/runs/32773331278 I noticed some issues with CORE-000540. The rule uncovered 2 large bugs--

While investigating why CORE-000540 (Findings About split dataset parent domain check) was intermittently failing to flag known violations —These are not specific to CORE-000540 in isolation; they affect any rule that validates split datasets, and likely explain sporadic, hard-to-reproduce validation inconsistencies across other rules in the engine.

Bug 1: Cache key collision in @cached("get_dataset")

Symptom: When a rule validated multiple datasets in a single run (e.g., FA, FA1, FACM), get_dataset() would only execute its body once — for whichever dataset happened to be processed first by self.data_service.get_datasets(). Every subsequent dataset's validation call silently received that same cached result instead of computing its own, because dataset ordering from get_datasets() is not guaranteed to be stable across runs.

Root cause: BaseDatasetBuilder.init unconditionally sets self.name = self.class.name and self.domain = dataset_metadata.unsplit_name. The cached() decorator's cache-key logic prioritized instance.name/instance.domain over the dataset-specific dataset_metadata.name/dataset_metadata.domain. Since self.name is the builder class name (identical across every dataset validated by that rule) and self.domain is the shared unsplit_name (identical across all split siblings), every builder instance for a given rule/split-family collapsed onto the same cache key — regardless of which specific dataset it was actually built for.

Fix: Updated cached() in decorators.py to prioritize dataset_metadata.name/dataset_metadata.domain (when a dataset_metadata attribute is present on the instance) over the instance's own generic .name/.domain, ensuring cache keys are correctly scoped per-dataset rather than per-builder-class or per-domain-group.

Bug 2: include_split_datasets did not implement its documented behavior

Symptom: Per the rules-engine documentation, setting domains.include_split_datasets: true is meant to "allow split datasets to be processed separately from their parent datasets... useful when you need to analyze split datasets independently." In practice, this flag did not achieve that. With it set to true:

The validation loop correctly called validate_single_dataset once per split sibling.
However, BaseDatasetBuilder.get_dataset()/get_dataset_contents() had no awareness of the flag at all, and continued to merge all split siblings together via concat_split_datasets regardless of its value — meaning each "independent" validation call actually evaluated the exact same merged, domain-wide view.
Separately, RulesEngine.validate_single_rule stored results keyed by dataset_metadata.unsplit_name, which is identical across all split siblings — so each of the three (redundant, identical) validation results overwrote the previous one, leaving only the last-processed dataset's result in the final output.

Fix:
get_dataset() and get_dataset_contents() now check include_split_datasets from the rule's domains config ((self.rule.get("domains") or {}).get("include_split_datasets", False)) and skip the concat_split_datasets merge when the flag is True, instead building/fetching only the current dataset's own data — matching the documented "process independently" behavior.
RulesEngine.validate_single_rule now stores results keyed by dataset_metadata.name when include_split_datasets is True, preventing split siblings' independently-computed results from overwriting each other.

[SFJohnson24]

https://github.com/cdisc-org/cdisc-open-rules/actions/runs/32980756607 see this--failures are sorting (which has been merged) as well as incorrect .env files which is being corrected in a PR I am putting up now