fix: pandas 3 and scikit-learn 1.9 compatibility, and improve dependency testing

[FBruzzesi]

pandas 3 made Day a calendar offset, so TimeGapSplit.summary()'s frequency column silently became 24h instead of D; it now emits the pandas 3 rendering on every supported pandas version.

scikit-learn 1.9 additionally runs check_array_api_input on estimators tagged array_api_support=False, so 11 such checks are declared expected failures with reasons.

CI could not have caught either: uv run re-synced the test job back to uv.lock, discarding the uv pip install it was meant to be testing, and the nightly "latest" job was pinned to Python 3.10, where pandas 3 and scikit-learn 1.9 do not install at all.

Both fixed, plus dependency floors that could never install (pandas>=1.1.5 fails to build, scikit-learn>=1.0 contradicts sklearn-compat) and the two-year-old numpy<2.0 cap. Dropping it needed cvxpy>=1.5.2, umap-learn>=0.5.8 and a numba floor, and lets the PR job finally reach pandas 3.
A new minimum-versions job verifies every bound with --resolution lowest-direct.

Breaking: summary()["frequency"] returns 24h where it previously returned D to align with pandas v3+ behavior.

[FBruzzesi]

1. Adding numpy to avoid it via transitive dependency, and pinning a min version
2. pandas 2.0.3 was released 3+ years ago (2023-06-28)
3. scikit 1.4.2 was released ~2.5 years ago (2024-04-09)

[FBruzzesi]

• cvxpy 1.5.2 was released 2+ years ago (2024-06-18)
• umap-learn 0.5.8 was released 1+ years ago (2025-06-30) - This is the most recent release in the bump. It allows us to pin numpy < 2.0

[FBruzzesi]

@koaning if we decide to go ahead with this one, I think it might be worth a minor version bump as it has quite some dependency version bumps AND one breaking change.