D135 — macOS 15: floating-point parsing without std::from_chars

Contributed by Chris Hemingway (@cHemingway) in pull request #46.

Decision

The macOS build supports macOS 15 as well as 26. Floating-point text is read through tmk::parse_double (core/parse_double.hpp): std::from_chars everywhere except Apple platforms, where it is strtod_l in the "C" locale held to from_chars' grammar (no leading space, + or hex; overflow and underflow to zero rejected, subnormals kept). Test scripts run under macOS's bash 3.2 (no mapfile; empty arrays expanded as ${a[@]+"${a[@]}"} under set -u)

Alternatives

Requiring macOS 26 (Apple's libc++ has floating-point from_chars only from there, and the Metal port was built on 26.4); a deployment target of 26 (the binary would not run on 15); strtod without a locale (reads 0,5 under a comma locale); Boost.Charconv (a new compiled dependency for four call sites); requiring Homebrew's bash for the tests

Reason

Macs on 15 could not build the engine at all. strtod_l is correctly rounded on both libcs, so the two paths give the same double: a unit test checks that bit for bit on Linux, and 2,000,000 strings through the macOS path against libstdc++'s from_chars gave 0 mismatches after subnormals were allowed (the first version rejected them, as strtod sets ERANGE for them). On macOS 15 the quick tier is byte-identical CPU against Metal (30/30) and matches the last Linux run board for board (25/30 clean, 99.0 %); DRC parity with native kicad-cli 10.0.6 holds (doc 07 §8.2, bench/records/macos15/)