results/results_fairness.csv and results_performance.csv don't reproduce for the COMPAS audit when regenerated today, even under the exact pinned environment

The issue is about regenerating CSV results for the COMPAS audit. Start by running python3 -m faircode benchmark COMPAS/audit.yaml --out results/ --no-plots from the repository root after verifying the environment matches requirements-lock.txt. Check the output files results/results_fairness.csv, results/results_performance.csv, and results/summary.csv for the 'compas' rows. Compare the new numbers with the committed ones to confirm they update. Ensure no other dataset rows change unexpectedly, then commit the updated CSVs.

Where: results/results_fairness.csv, results/results_performance.csv, results/summary.csv - specifically every compas,* row.

The gap: Re-running faircode benchmark against the unmodified, currently-committed COMPAS manifest and dataset, in an environment whose installed package versions exactly match the repo's own requirements-lock.txt, produces different numbers than what's currently committed in results/ for COMPAS - while German Credit Lending, run the same way, reproduces bit-for-bit.

Repro:

$ git status --short                                  # confirms clean checkout, nothing modified
(no output)

$ git hash-object "COMPAS/compas-scores-raw.csv"
f77a7c86f17df584f6e9087b8a8410a3c1c3964e
$ git show HEAD:COMPAS/compas-scores-raw.csv | git hash-object --stdin
f77a7c86f17df584f6e9087b8a8410a3c1c3964e               # identical to what's committed

$ pip list 2>/dev/null | grep -iE "^(scikit-learn|pandas|numpy|fairlearn) "
fairlearn                 0.14.0
numpy                     2.4.6
pandas                    3.0.3
scikit-learn              1.9.0
$ grep -iE "^(scikit-learn|pandas|numpy|fairlearn)==" requirements-lock.txt
fairlearn==0.14.0
numpy==2.4.6
pandas==3.0.3
scikit-learn==1.9.0        # installed versions match the repo's declared lock exactly

$ python3 -m faircode benchmark COMPAS/audit.yaml --out /tmp/bench_out --no-plots
Ran 1 audit(s), wrote 90 fairness rows and 45 performance rows to /tmp/bench_out/

$ grep "^compas,baseline,random_forest,race,demographic_parity_diff" /tmp/bench_out/results_fairness.csv
compas,baseline,random_forest,race,demographic_parity_diff,0.8493652148810584,0.8324541569672811,0.8654460156254798,0.0,True,1804,1444,False,
$ grep "^compas,baseline,random_forest,race,demographic_parity_diff" results/results_fairness.csv
compas,baseline,random_forest,race,demographic_parity_diff,0.8639161791052065,0.8483759968686193,0.8798248937131277,0.0,True,1788,1466,False,

The point estimate (0.8494 vs 0.8639), CI, and even the disadvantaged/advantaged test-set counts (1804/1444 vs 1788/1466 - different totals, 3248 vs 3254) all differ. This isn't run-to-run noise: rerunning locally twice gives the identical 0.8493652148810584 / 1804 / 1444 both times. The same check against German Credit Lending reproduces exactly:

$ python3 -m faircode benchmark "German Credit Lending/audit.yaml" --out /tmp/bench_gcl --no-plots
$ diff <(grep "^german_credit_lending,baseline,random_forest,age,demographic_parity_diff" /tmp/bench_gcl/results_fairness.csv) <(grep "^german_credit_lending,baseline,random_forest,age,demographic_parity_diff" results/results_fairness.csv)
(no output - identical)

So this isn't a general "results/ never matches" problem, and it isn't explained by an uncommitted dataset edit or an unpinned dependency - it's specific to COMPAS (at minimum), and results/'s file mtimes (24 Jul) predate several faircode/ code changes documented in CHANGELOG's [2.3.0] entry (13 Sep) that touched manifest.py/significance.py/metrics.py behavior - most likely the real cause: results/ for COMPAS was generated before one of those fixes and never regenerated after.

Fix direction: Regenerate results/ (faircode benchmark --out results/) against the current codebase and commit the refreshed CSVs, since CLAUDE.md now treats this as ordinary open development rather than frozen paper output. Separately, consider giving results/ its own lightweight provenance note (git commit + package versions), the way paper/results-frozen/MANIFEST.md already does, so a future drift like this is easy to catch by inspection instead of by a from-scratch rerun.