Revert the macOS Accelerate quarantine (PR #157) once the upstream Accelerate PRs are approved #159

What to revert

PR #157 quarantines TestQB.Polynomial_Decay_general1 on macOS so core-macos stops being permanently red. It is a single, self-contained commit touching only .github/workflows/core-macos.yaml (both build and build-asan) and the corresponding docs/CI.md entry, so it reverts cleanly.

Where the revert happens

In PR #155 (retire-legacy-accelerate), which already removes the legacy-Accelerate accommodations. Reverting the quarantine belongs there rather than in a standalone change: #155 is what makes the test pass again, so the two must land together or macOS goes red in between.

When

Once the upstream Accelerate work is approved and merged, in this order (icl-utk-edu/lapackpp#88 needs the defines.h from icl-utk-edu/blaspp#134):

1. icl-utk-edu/blaspp#134 — New Apple Accelerate support (continues the stalled icl-utk-edu/blaspp#74)
2. icl-utk-edu/lapackpp#88 — Support Apple's new Accelerate interface

How you will be told

The quarantine is deliberately not a blind exclusion. The test is still run, separately, and cannot fail the job:

• While it keeps failing, every macOS run prints a notice that the suppression is still needed.
• The moment it passes, the run prints DELETE THE macOS SUPPRESSION, naming the files to edit.

So the migration signal the old always-red arrangement was supposed to provide is preserved, and arrives as an instruction rather than a colour change nobody was watching.

Why it was quarantined at all

TestQB.Polynomial_Decay_general1 fails on Apple Silicon because Apple's old Accelerate LAPACK has a broken divide-and-conquer gesdd. Leaving it failing kept core-macos red on main and on every branch, which meant a genuine new macOS regression was indistinguishable from the known one — a lane that is always red reports nothing.