fix: #732 Windows WinHTTP linking + #692 'default' undefined symbol

[proggeramlug]

Summary

Two contained linker fixes reported on GitHub. Both are independent and self-contained; #678 (the third linker-tagged issue) is architectural and left for a separate scoped fix.

#732 — Windows: missing winhttp.lib

--target windows failed with lld-link: error: undefined symbol: __declspec(dllimport) WinHttpOpen (and seven sibling WinHttp* symbols), all referenced from perry_ui_windows::widgets::image::fetch_url_blocking.

Root cause: perry-ui-windows enables the windows crate's Win32_Networking_WinHttp feature, which emits #[link(name = "winhttp")] attrs in the rlib. Those attrs do NOT propagate through perry-ui-windows's staticlib crate-type to perry's final link line — perry invokes lld-link with its own hand-rolled Windows system-library list and winhttp.lib wasn't in that list.

Fix: append winhttp.lib to the Windows arm of crates/perry/src/commands/compile/link.rs's system-libs list.

#692 — undefined reference to 'default'

A literal symbol named default at link time. Reproducer is a single-file TS importing a default export from a module Perry can't resolve as native:

import sanitizeHtml from "sanitize-html";
sanitizeHtml("<b>hi</b>");

Root cause chain:

1. HIR's register_imported_func (lower.rs:3727) registers default-import bindings under the local name with the original-name sentinel "default".
2. Identifier lookup (lower.rs:7175) resolves the local to Expr::ExternFuncRef { name: "default" }.
3. Codegen's call path (lower_call.rs:735+) falls through every special-case (setTimeout/jsx/perry-system/js_* builtin) and the import_function_prefixes map (which only contains NativeCompiled imports, NOT V8-fallback JsModule imports — so sanitize-html has no entry).
4. The fallthrough at lower_call.rs:848+ emits call double @default(...) and the system linker has no such symbol → undefined reference to 'default'.

Fix: before the native-library fallthrough, detect name == "default" with no import_function_prefixes entry — the only producer of bare-"default" ExternFuncRefs is the default-import-from-unresolved-module path — and route to a new runtime stub js_unresolved_default_call (crates/perry-runtime/src/object.rs) that returns NaN-boxed TAG_UNDEFINED and prints a one-shot diagnostic on first call. Args are still lowered for side effects (string interning, closure collection).

After the fix, the minimal repro links and runs:

perry: called a default-imported binding from an unresolved module (returns undefined). The module's default export was not found in perry-stdlib or perry.compilePackages — run `perry --print-api-manifest` to see what's supported.
result: undefined

Not in this PR — #678

_perry_fn_..._render unresolved symbols for V8-fallback modules referenced from native modules are architectural: codegen either needs to route through js_call_function when the callee module is V8-fallback (requires threading ModuleKind to codegen) or emit weak stub symbols for V8-fallback module exports (requires threading the JsModule export surface). Tracked separately on the issue.

Test plan

• cargo build --release -p perry-runtime -p perry-codegen -p perry — clean
• Pre-fix repro (import sanitizeHtml from "sanitize-html") → linker error reproduces locally on Windows
• Post-fix repro → links, runs, prints diagnostic + result: undefined
• CI green (lint, cargo-test, parity, compile-smoke, api-docs-drift, security-audit)
• Manual: external user with --target windows confirms WinHTTP linkage