Fix floatbar taskbar z-order

[lwchang018]

Summary

• Add an event-driven Windows z-order guard for floatbars overlapping primary or secondary taskbars.
• Reassert the native topmost state after window move/resize and relevant shell foreground/reorder events.
• Avoid repair work while the floatbar is hidden and report native SetWindowPos failures.

Root cause

The Windows taskbar and the floatbar are both topmost windows. Clicking or reordering the taskbar can place it ahead of the floatbar within the topmost band without clearing the floatbar's WS_EX_TOPMOST style. The existing implementation only reasserted topmost state during show, resize, or settings changes, so it did not react to later shell z-order changes.

User impact

A floatbar placed over an empty taskbar area remains visible after another empty taskbar area is clicked. The guard only repairs z-order while the floatbar actually overlaps a taskbar.

Validation

• cargo +stable-x86_64-pc-windows-gnu test --offline --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml — 316 passed.
• cargo +stable-x86_64-pc-windows-gnu clippy --offline --manifest-path apps/desktop-tauri/src-tauri/Cargo.toml --all-targets -- -D warnings — passed.
• pnpm test — 153 passed.
• pnpm run build — passed.
• pnpm run tauri:build:debug — passed.
• Native Windows z-order regression: after the taskbar was moved ahead, the overlapping floatbar automatically recovered within 150 ms; the guard did not intervene when the floatbar was moved away from the taskbar.

[Finesssee]

Thanks for the PR, I will review this ASAP.

[Finesssee]

Approved — thermo-nuclear + ponytail review

Root cause and repair primitive are correct: taskbar + floatbar share the topmost band; shell activation can reorder without clearing WS_EX_TOPMOST. Reasserting via SetWindowPos(HWND_TOPMOST | SWP_NOACTIVATE) after shell z-order events (and on move/resize) is the right Win32 fix.

Preferred cleanup (non-blocking; please track soon after merge):

1. Filter WinEvent hwnd to taskbar shells (Shell_TrayWnd / Shell_SecondaryTrayWnd) before scheduling reassert — do not treat every system FOREGROUND/REORDER as relevant while the bar is active (overlap only gates repair, not main-thread work).
2. Consider a thinner trigger (visibility-scoped 100–150ms timer like auto_refresh, or cut the hooks module roughly in half). 266 lines + globals is heavy for “debounce → apply_always_on_top”.
3. Clear FLOATBAR_ACTIVE on Destroyed / missing webview, not only happy-path hide.

Ponytail: ~80–150 lines shaveable if timer path or filtered hooks + statics.

Shipping the user-visible fix now; structure cleanup is preferred follow-up, not a hard block.