fix(random): LINK.EXE reads -lbcrypt as an option named l

The MSVC conformance row still failed after the last commit named the
library, because it named it in the other side's spelling. `ldflags`
reaches the command line verbatim, and the two rows this predicate
selects do not drive the same program:

    LINK : warning LNK4044: unrecognized option '/lbcrypt'; ignored
    random.obj : error LNK2019: unresolved external symbol
                 __imp_BCryptGenRandom

clang drives lld-link and translates GNU spellings for it; `msvc@system`
drives LINK.EXE directly, and LINK reads `-` and `/` as the same option
prefix.

One spelling serves both. Measured, rather than assumed, before changing
the row that was already green:

    clang --target=x86_64-pc-windows-msvc -fuse-ld=lld -### t.c bcrypt.lib
        → 'bcrypt.lib'
    clang --target=x86_64-pc-windows-msvc -fuse-ld=lld -### t.c -lbcrypt
        → "bcrypt.lib"

The clang link line is byte-identical under both, so this cannot regress
the row it is not aimed at.

Author: Sunrisepeak

mcpp.toml

@@ -66,8 +66,24 @@ ldflags = ["-lntdll", "-lsynchronization", "-lshell32", "-lkernel32", "-lbcrypt"
 # ⚠️ The predicate above is `not(env = "msvc")`, so neither row saw the entry
 # there. The library is named once per side because the two sides spell a
 # library differently and share no list.
+#
+# ⭐ AND THE SPELLING HERE IS `bcrypt.lib`, NOT `-lbcrypt`. `ldflags` reaches
+# the command line verbatim; mcpp's dialect abstraction covers the flags it
+# generates itself, not the ones a manifest writes. The two rows this
+# predicate selects do not drive the same program: clang drives lld-link and
+# translates for it, while `msvc@system` drives LINK.EXE directly, and LINK
+# reads `-` and `/` as the same prefix — so `-lbcrypt` arrives as an option
+# named `l`:
+#
+#     LINK : warning LNK4044: unrecognized option '/lbcrypt'; ignored
+#     random.obj : error LNK2019: unresolved external symbol __imp_BCryptGenRandom
+#
+# One spelling serves both, which is why this stays a single entry. Measured
+# with `clang --target=x86_64-pc-windows-msvc -### … -fuse-ld=lld`: the driver
+# emits `bcrypt.lib` to lld-link for `-lbcrypt` and for `bcrypt.lib` alike, so
+# the clang link line is unchanged by this and only LINK.EXE sees a difference.
 [target.'cfg(all(windows, env = "msvc"))'.build]
-ldflags = ["-lbcrypt"]
+ldflags = ["bcrypt.lib"]
 
 # Exceptions and run-time type information, on the one ABI where their absence
 # is asserted.