sort/sort_by order equal elements by the platform qsort: unstable on macOS, stable on glibc (fixed on phase2 f7191b7e) #1982

sort and sort_by call the platform qsort. glibc's is in practice a stable merge sort; macOS's qsort is not stable. So equal elements, or equal sort_by keys, can come out in a different order on macOS than on Linux, with no error. That is a silent cross-platform divergence: a program, and a recorded tape replayed on another OS, can disagree.

How it surfaced: phase2-numbers R1.7. N6 prints an integral float as 3.0 and an int as 3, so an int/float tie that sorted "equal" became visible in text, and tests/test_boxed_int_containers.eigs ("sort exact order") failed on the macOS lane only (full lane run 40271709027). On main the same instability is reachable through sort_by with equal keys on distinguishable elements.

Fixed on phase2: in the R1.7 fix-forward (commit f7191b7e, on phase2-numbers since f406359), sort and sort_by are STABLE on every platform: a merge sort with an index tie-break, independent of libc, the freestanding eigs_qsort path included. BUILTINS.md documents it. A forced-quicksort plant reds the test.

Done when

• Main's sort/sort_by are stable on every platform: either Phase 2 (Phase 2 numbers: exact int64 and IEEE doubles (#1758) #1776) lands with f7191b7e, or the fix is ported to main first if Phase 2 is not landing soon.
• A test with many ties pins the stable order, and it fails under an unstable sort.