fix(port): 判据是「哪个 C 库」,不是「哪个 C 库,在 Apple 上」

覆盖里原来写的是 `_LIBCPP_HAS_MUSL_LIBC && defined(__APPLE__)`,因为 Apple 是
第一个暴露它的目标。实测 2026-08-23 的第二个:x86_64-windows-gnu 在 openkal 上走
_LIBCPP_MSVCRT_LIKE → support/windows.h,停在 `_locale_t` —— 那是微软的 C 运行时,
而这个程序的 C 库是 musl。同一个形状,第二种目标格式。

⇒ 把规则收窄到一个平台,就意味着每个平台再写一遍。upstream 问的是「底下是哪个
C 库」;这里回答它,于是每一个答案是 musl 的目标都到达同一个后端 —— 而在 ELF 上
那本来就是它到达的那个。

Author: speak-agent

port/include/__locale_dir/locale_base_api.h

@@ -52,10 +52,19 @@
 
 #include <__config>
 
-#if _LIBCPP_HAS_LOCALIZATION && _LIBCPP_HAS_MUSL_LIBC && defined(__APPLE__)
-// The one case upstream's chain answers wrongly for this configuration. Every
-// other target — including musl on ELF, where `__linux__` is defined and the
-// chain already reaches the same header — falls through to upstream below.
+// ⭐ THE PREDICATE IS THE C LIBRARY, FULL STOP — NOT "the C library, on Apple".
+//
+// It was `&& defined(__APPLE__)` at first, because Apple was the target that
+// exposed it. Measured 2026-08-23 on the next one: `x86_64-windows-gnu` over
+// openkal takes `_LIBCPP_MSVCRT_LIKE` → `support/windows.h` and stops on
+// `_locale_t`, which is Microsoft's C runtime, for a program whose C library
+// is musl. Same shape, second object format.
+//
+// ⇒ Narrowing the rule to one platform would have meant writing it again per
+// platform. The question upstream asks is which C library is beneath; this
+// answers it, and every target where the answer is musl now reaches the same
+// backend — which on ELF is the one it already reached.
+#if _LIBCPP_HAS_LOCALIZATION && _LIBCPP_HAS_MUSL_LIBC
 #  include <__locale_dir/support/linux.h>
 #else
 #  include_next <__locale_dir/locale_base_api.h>