docs: the first diagnosis read mingw's contents, and mingw is not part of this

⚠️ 我判断 `ProcessPrng` 不可用的依据是 `/usr/x86_64-w64-mingw32/lib` 里
没有它。**那个参照物是错的** —— mingw 不属于这套体系,它正是
`build.mcpp` 开头那段注释所说、这个包写出来就是为了不再依赖的东西:

> files that exist on a machine with mingw installed and nowhere else …
> a green that came from history the new machine does not have

本后端链接的要么是厂商 SDK(Windows 宿主),要么是本包从 `port/*.def`
自己生成的(交叉时),**从来不是第三方的**。

结论仍然成立,理由换成对的:Windows SDK 出 `bcrypt.lib` 而**不出**
`bcryptprimitives.dll` 的导入库 —— `ProcessPrng` 文档化了却没有 `.lib`。
`BCryptGenRandom` 由 `bcrypt.lib` 列出,两条路都能解析。

Author: Sunrisepeak

port/bcrypt.def

@@ -5,10 +5,12 @@
 ; handle would give openkal.random an initialisation order it does not have.
 ;
 ; ⚠️ `ProcessPrng` (bcryptprimitives.dll) was tried first: fewer moving parts,
-; and what Chromium and Rust use. It fails on a WINDOWS HOST, where this file's
-; generated import libraries are not built at all --- `build.mcpp` returns
-; immediately there, a real SDK being present --- and no SDK in either toolchain
-; exports that name. `libbcrypt.a` exports the name below on both.
+; and what Chromium and Rust use. It fails on a WINDOWS HOST, where these
+; generated libraries are not built at all --- `build.mcpp` returns immediately
+; there, the vendor's own being present and complete --- and the Windows SDK
+; ships no import library for `bcryptprimitives.dll`. The name below is listed
+; by `bcrypt.lib`, so it resolves through the vendor's libraries and through
+; this file alike.
 ;
 ; Generated into an import library by build.mcpp; see port/README.md.
 LIBRARY bcrypt.dll

src/random.cpp

@@ -9,16 +9,28 @@
 // takes a null handle, which is exactly what is wanted here.
 //
 // ⚠️ AND NOT `ProcessPrng`, WHICH WAS TRIED FIRST AND FAILS ON A WINDOWS HOST.
-// That name lives in `bcryptprimitives.dll` and no import library in either
-// toolchain exports it: mingw ships `libbcrypt.a` and not the primitives, and
-// this package generates its own import libraries only when cross-compiling
-// (`build.mcpp` returns immediately on a Windows host, where a real SDK is
-// present). Measured — the cross build linked and the native one did not:
 //
 //     lld-link: error: undefined symbol: __declspec(dllimport) ProcessPrng
 //
+// The cross build linked and the native one did not, and the asymmetry is in
+// where the import library comes from. Cross-compiling, this package generates
+// its own from `port/*.def` — a list of names, so a name it lists is a name it
+// has. On a Windows host `build.mcpp` returns immediately and the VENDOR's
+// import libraries are used, because they are present and complete; and the
+// Windows SDK ships `bcrypt.lib` but no import library for
+// `bcryptprimitives.dll`. `ProcessPrng` is documented and has no `.lib`.
+//
 // ⭐ A backend that links on one host and not another is not a backend. The
-// name below is in `libbcrypt.a` on both.
+// name below is exported by `bcrypt.dll` and listed by `bcrypt.lib`, so it
+// resolves through the vendor's libraries and through this package's generated
+// one alike.
+//
+// ⚠️ THE FIRST DIAGNOSIS OF THIS WAS WRONG AND IS RECORDED SO IT IS NOT REPEATED:
+// it read `/usr/x86_64-w64-mingw32/lib` and concluded from mingw's contents.
+// mingw is not part of this ecosystem — it is the very thing `build.mcpp`
+// exists to stop depending on, as the note at the top of that file says. What
+// this backend links against is either the vendor's SDK or this package's own
+// generated libraries, and never a third party's.
 #include "win.h"
 #include <openkal/random.h>