Win+L / LockWorkStation silently fails to lock screen (likely mutex deadlock in sync_hash_map.rs swallowing the lock hook)

Description

Pressing Win+L does nothing at all - no lock screen appears, and no Windows Security-log lock event (4800/4801) is generated. Reproducible via three independent trigger paths:

1. Physical Win+L keypress
2. On-screen keyboard Win+L (mouse-only, rules out physical hardware fault)
3. Direct API call: rundll32.exe user32.dll,LockWorkStation (bypasses the keyboard shortcut entirely)

All other Win+ shortcuts (Win+E, Win+D, Alt+Tab, Ctrl+C/V) work normally - only the lock function is affected.

Environment

• Seelen UI version: 2.8.2.0 (latest stable at time of report)
• OS: Windows 10.0.26200
• Install: MSIX (WindowsApps)

Diagnosed root cause

Seelen UI.log is flooded with repeated internal errors:

Cause: App("Mutex lock timed out after 5s.\n  Last lock acquired at: src\background\\\utils\lock_free\sync_hash_map.rs:89:16")
Location: src\background\\\utils\lock_free\sync_hash_map.rs:89:16

This repeats continuously (hundreds of occurrences), suggesting an internal deadlock in the sync_hash_map implementation used by background event/state tracking.

Related issues (#956, #762, #1734) confirm Seelen UI hooks Win+L/lock-state transitions to manage its own overlay UI visibility. It seems very plausible the deadlocked internal state tracker causes this hook to swallow the Win+L event before it reaches the actual Windows LockWorkStation call - with no exception surfaced, no visible failure, and no security-log trace.

What I've ruled out

• Hardware keyboard fault
• Windows accessibility hotkeys (Sticky/Filter/Toggle Keys)
• Registry scancode remap / NoWinKeys / DisableLockWorkstation / NoLockWorkstation policies
• Group Policy / local security policy (none applied - standalone workstation)
• RDP session (this is a local console session)
• Malware/leftover persistence (verified clean)
• Winlogon Shell/Userinit/Notify tampering (all default/clean)
• Seelen UI's own settings_shortcuts.json (enabled: false, empty shortcuts - toggling this had no effect)
• unlockShortcuts setting in settings.json (toggling true/false had no effect on the lock issue)

Workaround

Fully exiting seelen-ui.exe and its watchdog slu-service.exe restores native Win+L functionality immediately, confirming Seelen UI is the interceptor.

Expected behavior

Win+L should lock the screen normally while Seelen UI is running, exactly like all other Win+ shortcuts.