macOS: Accelerate ILP64 blocked on a LAPACK++ compile bug (icl-utk-edu/lapackpp#89)

[mmelnich]

Split out of #165, whose other items (new-interface default, gesdd correctness, no Homebrew prerequisite) land with #172.

BLAS++ ILP64 on new Accelerate works (blas_int=int64 selects ACCELERATE_LAPACK_ILP64; RandBLAS uses it in CI as of BallisticLA/RandBLAS#198). LAPACK++ does not compile in that configuration: its config.h typedefs lapack_int to long (Apple's __LAPACK_int) while the wrappers' ILP64 no-copy paths assume lapack_int == int64_t (long long on Darwin). First failing file is src/gbcon.cc. Upstream: icl-utk-edu/lapackpp#89.

Because RandLAPACK always needs LAPACK++, the installer constrains Accelerate to LP64 for now and refuses --blas-int=ilp64 with a message citing this issue.

Done when

• the upstream fix merges (issue CMake: resolving build error "string sub-command REGEX, mode REPLACE needs ... " #89, whichever direction Mark prefers)
• the LAPACK++ pin advances past it
• install/install.sh lifts the Accelerate LP64 constraint (width policy falls back to the standard prefer-ILP64 rule)
• the install-macos assertion flips from accelerate, LP64 to accelerate, ILP64
• INSTALL_SCRIPT.md 6.1/6.2 and INSTALL.md rows update accordingly

Note: RandBLAS's --examples path also builds LAPACK++, so on macOS with ILP64 Accelerate it hits the same upstream bug; nothing to change there, it lifts with the same fix.