Add ScoringBench integration and harden release evidence

[jxucoder]

What changed

• add a pinned, upstream-shaped ScoringBench integration with separate smoke, official-quality, and scale-extension protocols
• run an official-protocol 1027_ESL quality sentinel on Linux and freeze its manifest, dataset registry, and raw fold-level Parquet results
• add CI/source-head/merge-SHA provenance and keep upstream-generated dataset artifacts out of the source checkout
• add a canonical AGENTS.md plus a learnings/ engineering log
• preserve categorical split state across model save/load
• fail fast for categorical tree splits above the current uint64 representation limit
• fail fast when the reserved high-level batch_size option is set
• replace unsupported GPU, out-of-core, GOSS, and multi-GPU performance claims with explicit capability boundaries
• replace the fresh-runner no-op performance check with a same-runner comparison between the previous remote main and the pushed revision
• isolate JAX tests, stop rerunning the core suite downstream, cache compiled Numba kernels, and bound/cancel superseded CI runs

Why

OpenBoost needs externally reproducible evidence before it can credibly claim a niche in distributional tabular boosting. The existing benchmark and scaling documentation overstated several unverified paths, while categorical persistence and cardinality handling could silently change predictions.

This PR establishes a truthful benchmark path, fixes identified correctness bugs, records failures as well as successes, and makes unsupported scaling behavior explicit.

First real-dataset evidence

The frozen ScoringBench shard is in benchmarks/evidence/scoringbench/1027_esl_20260816/.

Protocol: ScoringBench commit a938a667..., 5 folds, 3,000-row cap, OpenBoost NaturalBoost Normal CPU vs NGBoost Normal, 500 rounds, learning rate 0.01, depth 3, seed 42.

Descriptive means:

• CRPS: OpenBoost 0.300527 vs NGBoost 0.307714 (-2.34%), but OpenBoost wins only 2/5 folds
• log score: OpenBoost 0.710078 vs NGBoost 0.675967 (+5.05%, worse)
• RMSE: OpenBoost 0.545923 vs NGBoost 0.554927 (-1.62%)
• 90% interval score: OpenBoost 2.436058 vs NGBoost 2.737215 (-11.00%)
• 90% coverage: 0.854723 vs 0.813718; OpenBoost is closer to 0.90 in 5/5 folds
• fit time: 2.111s vs 3.299s (1.56x), but cold/warm timing is not separated

This is one small dataset, not a library-level quality or speed claim.

Verification

• latest ScoringBench workflow: run #7, passed
• latest Tests workflow: run #71, passed
• official sentinel artifact: Actions artifact 9256929555, digest sha256:0c5176c4a28cd44444f6a086643a01f636b0dcb5e165a4a30d3d992f3e96da97
• ScoringBench result gate: 10 fold/model rows, official-quality-shard protocol, clean source and upstream checkouts
• focused local provenance/shard tests: 4 passed
• distributional regression tests: 47 passed
• persistence/categorical tests: 34 passed
• categorical/growth tests: 46 passed
• large-scale/core/loss tests: 77 passed
• performance harness tests: 4 passed
• focused Ruff checks, Python compilation, MkDocs, slow tests, and executable documentation examples: passed

Remaining evidence gate

Keep this PR draft. One sentinel is not sufficient. Before any broad value claim:

1. run and publish the complete official ScoringBench suite, including failures and paired uncertainty/ranking;
2. submit the wrapper/results upstream for independent review;
3. run a separately labeled real-data scale extension on multiple dataset sizes;
4. establish CPU/CUDA predictive parity, then report cold and warm timings, peak memory, hardware, versions, seeds, and failures.