Windows: whoami crate's GetUserNameExW link fails on every doc-test (missing secur32 import lib) #220

Context

The Windows doc-tests gate (doc-tests (windows-2022, perry-ui-windows, …)) is currently red on main for every example that pulls in perry-stdlib. Three concrete failures, all the same root cause:

COMPILE_FAIL  getting-started/npm_packages.ts
COMPILE_FAIL  stdlib/database/snippets.ts
COMPILE_FAIL  stdlib/overview/snippets.ts

Each fails at the link step with:

perry_stdlib.lib(whoami-...rcgu.o) : error LNK2019: unresolved external symbol
  __imp_GetUserNameExW referenced in function
  _ZN6whoami2os6target13extended_name17h41c61ee89249a2d9E
fatal error LNK1120: 1 unresolved externals

Root cause

__imp_GetUserNameExW is a Win32 system symbol exported from Secur32.dll / secur32.lib. The whoami Rust crate (transitively pulled into perry-stdlib) calls it for its extended_name API, but the link line that perry generates for native Windows targets doesn't include -lsecur32. The MSVC linker can't resolve the symbol and bails.

This is a single-fix issue: one missing #[link] annotation (or equivalent) makes all three failing examples link cleanly.

Three possible fix shapes

Pick the smallest one:

1. #[link(name = "secur32")] extern block in whichever Perry crate uses whoami (most likely perry-stdlib/src/system.rs or wherever os.userInfo() / os.username() is wired). Cleanest if the call site is centralized.

2. build.rs cargo:rustc-link-lib=secur32 in perry-stdlib's build.rs (or add one if missing), gated on target_os = "windows". Cleanest if there's no single Rust call site to attach the annotation to.

3. Perry's link line — pass -lsecur32 as part of perry's Windows link command in crates/perry-codegen/src/linker.rs. Mirrors the existing platform-specific link-line additions (e.g. -framework AppKit on macOS). Right answer if perry-stdlib is a static lib that delegates link flag selection to the consumer (perry).

The third option is the most likely correct shape for Perry's architecture (perry-stdlib is a static archive, perry handles all link-line construction). Verify by reading crates/perry-codegen/src/linker.rs — there's an existing Windows section adding kernel32.lib/user32.lib/etc.

Acceptance

• All three examples (getting-started/npm_packages.ts, stdlib/database/snippets.ts, stdlib/overview/snippets.ts) compile + link cleanly on the Windows doc-tests CI runner.
• No regression on macOS / Linux doc-tests gates.
• If using approach (3), document the addition with a comment matching the existing Windows-link-flags style in linker.rs.
• (Bonus) Audit other Win32 system libs that whoami and friends might need: advapi32.lib is already typically included; verify nothing else from the same family is silently dead-code-eliminated.

Pointers

• Failing job (latest red main run): gh run list --branch main --workflow=Tests --limit 1 --json databaseId
• whoami usage in perry-stdlib: grep -rn "whoami" crates/perry-stdlib/
• Perry's Windows link-line construction: crates/perry-codegen/src/linker.rs — search for windows / msvc to find the existing per-target link-flag block.
• Sister failure (already filed): doc-tests: wasm_snippets.ts banner should constrain to // targets: wasm — currently fails to link on every native target #219 — wasm_snippets.ts banner constraint, also affects Windows but separate root cause.

Sandbox-friendliness

A Linux cloud worker CAN fix this end-to-end without a Windows machine: the change is Rust source (link annotation or linker.rs string), Linux/macOS builds stay unaffected (cfg-gated), and Windows CI validates the fix. No need for a Windows-specific runner.

Estimated size

Tiny — one line in the right place. ~2-5 LOC plus a comment.