Retire legacy-Accelerate accommodations: macOS runs the full library

[mmelnich]

✅ Upstream requirement met (2026-08-27)

The gate this PR was waiting on has cleared: icl-utk-edu merged the new-Accelerate support in both BLAS++ (icl-utk-edu/blaspp#134) and LAPACK++ (icl-utk-edu/lapackpp#88) on 2026-08-27. core-macos builds its dependencies from the icl-utk-edu masters, so it now exercises the new interface for real.

Refreshed 2026-08-27, same scope plus:

• main merged in (the branch was 6 commits behind).
• The TestQB.Polynomial_Decay_general1 quarantine from TEMPORARY: quarantine the macOS Accelerate gesdd test (revert after Mark's BLAS++/LAPACK++ review) #157 is reverted here, per Revert the macOS Accelerate quarantine (PR #157) once the upstream Accelerate PRs are approved #159: this PR is what makes the test pass, so the two must land together. Closes Revert the macOS Accelerate quarantine (PR #157) once the upstream Accelerate PRs are approved #159.
• Accidentally committed build/ artifacts removed from the branch, and a top-level build/ entry added to .gitignore so they cannot recur.
• The core-macos dependency-cache key gained an accelerate tag, because earlier caches hold a BLAS++ built without -Dblas=accelerate and a cache hit would skip the new-interface guard.
• Linux verification against the refreshed branch: 772/772 tests pass (Release, oneMKL).

What this PR does

Makes macOS a full-library, first-class platform by removing all 18 __APPLE__ guards, and switches macOS CI to Apple's new Accelerate interface.

Background. Apple ships two LAPACKs in Accelerate. The legacy default is 3.2.1 (2009): gesdd returns wrong results on Apple Silicon (the reason core-macos has carried a deliberately red canary test), and routines RandLAPACK needs (orhr_col, geqrt, ...) don't exist — the reason BQRRP threw "not supported" on every Mac and ten benchmarks were stubbed out. The new interface (macOS ≥ 13.3, ACCELERATE_NEW_LAPACK, LAPACK 3.12 on current SDKs) fixes both, verified on this repo's CI: run 31065130007 — 311/311 tests pass on macOS, including the gesdd canary, all of TestBQRRP (first macOS execution ever), and test_orhr_col.

Changes:

• Drivers: BQRRP's runtime "not supported on Apple" throw removed; HQRRP's CholQR-path stub removed; CQRRPT's BQRRP-subroutine path enabled on macOS.
• Tests: test_bqrrp (whole file), the guarded sections of test_cqrrpt/test_hqrrp/test_bqrrp_gpu, and test_orhr_col now compile everywhere — macOS gains 16 tests.
• Benchmarks: the ten "cannot run on Apple machines" stub mains removed; real benchmark code everywhere.
• CI: core-macos builds BLAS++ with -Dblas=accelerate and hard-fails if the new interface wasn't selected (no silent legacy fallback). The canary test is included and expected green — the canary era ends with this PR.
• Docs: INSTALL.md documents the macOS requirement (new interface or Homebrew OpenBLAS; install.sh on macOS uses OpenBLAS and is unaffected). docs/CI.md replaces the quarantine entry with the new-Accelerate arrangement.

Follow-up, not in this PR: advancing the pinned BLAS++/LAPACK++ commits in install/install.sh and the Windows CI provisioner, allowing Accelerate ILP64, and re-evaluating the macOS installer default are tracked in #165 (RandLAPACK) and BallisticLA/RandBLAS#189.

[mmelnich]

CI on the refreshed branch, first run against the merged upstream masters:

• core-macos build (Release): green. The un-quarantined TestQB.Polynomial_Decay_general1 passes on Apple's new Accelerate, along with the full suite including TestBQRRP. This is the flip the PR was designed around.
• core-linux (both jobs), install-linux/macos/windows, and all Windows legs: green.
• core-macos build-asan (Debug/asan, not a required check): one failure, TestBQRRP.BQRRP_half_zero_luqr, and it is numerical rather than a sanitizer report (ASAN is silent). The factorization itself is fine (relative residual 5.7e-14, orthogonality 7.4e-15, rank 1000/1000); the max-col-norm pivot-quality metric lands at 1.06e-12 against the eps^0.75 = 1.03e-12 bound, a 3% overshoot (test_bqrrp.cc:105, actual 8.242e-11 vs 8.014e-11). The same test passes in the Release job on the same runner and BLAS, so the difference is Debug codegen in RandLAPACK's own kernels, not Accelerate misbehavior. This is also the first Debug/asan execution of TestBQRRP on macOS ever, so the tolerance has never been calibrated for this configuration.

I have deliberately not touched the tolerance: atol = eps^0.75 is shared by every BQRRP test and carries no dimension factor, so widening it is a test-design decision. Options: (a) add a modest constant or dimension factor to the pivot-quality bound, (b) leave it and treat this as a known-marginal configuration until the asan lanes become required. Happy to implement either.

[mmelnich]

Root cause of the build-asan failure found, and it is a test bug, not a tolerance problem — 08a36b8 fixes it, so the options in my previous comment are moot.

The max-col-norm metric measures the largest residual column with its full length, nrm2(m, ...), but the reference denominator used nrm2(n, ...) — only the first n of m entries of that column of the original A. For tall matrices that under-measures ||A_j|| by about sqrt(m/n), so the check enforced a bound roughly 58% tighter than the intended ||(A - QR)_j|| <= atol * ||A_j|| on the 5000x2000 test. The asan run's 3% overshoot was against that too-tight bound; with the correct denominator it passes with ~1.5x margin. As a bonus, on a wide matrix (m < n) the old line reads past the end of the last column of the copy.

The same copy-pasted helper exists in six test drivers (test_bqrrp, test_hqrrp, test_cqrrpt, test_cqrrt, test_bqrrp_gpu, test_cqrrpt_gpu); all six are fixed. atol = eps^0.75 is untouched. Linux/MKL Release: 772/772 after the change.