tray/native.rs: ~15 remaining Windows compile errors after Result-shadowing fix (PR #163)

[elasticdotventures]

Context

crates/ledgerr-host/src/tray/native.rs and settings_backend/windows_registry.rs have never successfully compiled for the Windows target — ledgrrr's own CI (.github/workflows/) has no job that builds for windows-latest, so this code (landed via #130/#131/#136, currently on b00t-patches / PR #163) went untested. It was first actually compiled by the downstream promptexecution/_b00t_ repo's package-windows workflow when PR #911 exercised it (CI run 30744620673), which failed with ~20 distinct errors.

Three of those (a Result-shadowing glob import in windows_registry.rs, an invalid WM_APP + 1 match pattern, and a missing windows::core::w macro import) have been fixed and pushed directly to b00t-patches (commit 5d21bd7). The rest are tracked here — I was not able to verify these against the real windows-rs 0.62 API (no Windows/mingw toolchain available in the environment that found them), so treat the groupings below as a starting map, not a confirmed diagnosis.

Remaining errors (original line numbers, pre-5d21bd7)

crates/ledgerr-host/src/tray/native.rs:

• E0433: cannot find type PCWSTR in this scope — lines 293, 299, 310, 342, 458, 459. PCWSTR is used throughout but apparently never actually resolvable in this file; likely needs an explicit use windows::core::PCWSTR; (not covered by the Win32::* glob imports already present).
• E0425: cannot find function, tuple struct or tuple variant BOOL in this scope — line 194 (fIcon: BOOL(1) in an ICONINFO literal). Same shape as the PCWSTR issue — possibly needs use windows::Win32::Foundation::BOOL; explicitly, or the windows 0.62 API no longer exposes BOOL as a tuple-struct constructor.
• E0308: mismatched types — lines 157, 174, 188 area, 204, 205, 248, 454, 486. Several cluster around create_icon_from_rgba's CreateDIBSection/ICONINFO/BITMAPINFO construction and CreateWindowExW/RegisterClassW calls — consistent with this code being written against a different minor version of windows-rs than what's pinned (0.62), where FFI signatures (Option<T> wrapping, pointer nesting, BOOL vs bool) have shifted.
• E0599: no method named is_closed found for struct std::sync::mpsc::Sender<T> — line 401. This one looks like a real logic bug rather than API drift: std::sync::mpsc::Sender has never had is_closed() — that method exists on tokio::sync::mpsc::Sender. Either swap to the tokio channel or replace the check with a send() result check.
• E0277: the trait bound dyn StdError: Send/Sync/Sized is not satisfied (via ?) — lines 465, 501. Something expects Box<dyn std::error::Error + Send + Sync> (likely because the error crosses a thread/channel boundary via std::thread::spawn or similar) but the local Result<_, Box<dyn std::error::Error>> return types don't carry those bounds.

Suggested next step

Whoever picks this up will need an actual Windows build environment (or at minimum gcc-mingw-w64-x86-64 + rustup target add x86_64-pc-windows-gnu for cargo check, though note some transitive deps' build scripts may still require a real x86_64-w64-mingw32-gcc linker probe) to iterate with real compiler feedback rather than guessing further.

Related: #143 (backends landed but not wired into ledgerr-host).