[RayTrunk]

What changed
TaskbarHider::configure now keeps the controller when the first reapply fails, the same way later failures already work. hide() is renamed to start() (private): it takes the snapshot and starts the watchdog and the show hook. configure stores the controller first and then calls reapply.

Why
This is the Explorer interaction from #28. Explorer and Wisp events side by side, from an out-of-process WinEvent hook on Explorer plus timestamps in Wisp:

    18 ms  Wisp      ABM_SETSTATE (auto-hide on)
    95 ms  Wisp      SW_HIDE primary taskbar      (returns after 317 ms; Explorer is busy)
   416 ms  Wisp      SW_HIDE second screen's taskbar
   440 ms  Explorer  HIDE second screen's taskbar
   443 ms  Explorer  SHOW second screen's taskbar   <- Explorer shows it again 3 ms later
   445 ms  Wisp      "A taskbar remained visible after SW_HIDE"
                     -> controller dropped, snapshot restored
   940 ms  Explorer  SHOW primary taskbar           (from the restore)
  2991 ms  Wisp      next try, same pattern

While Explorer is still switching the primary taskbar to auto-hide (it keeps moving it until about 650 ms), it shows a second screen's taskbar again right after Wisp hides it. On the first hide, Wisp treats that as fatal: it restores the taskbar, starts a new watchdog and tries again 2 s later. Later failures already keep the controller, and the show hook hides the taskbar on Explorer's next show. The first hide now works that way too.

If every retry fails, the outcome is the same as for a failure later on: after TASKBAR_ATTEMPTS the user gets the "Could not change the taskbar" notification, and the controller stays until Wisp quits or hide_taskbar is turned off, both of which restore the snapshot.

How I verified it
Windows 11 26H2 (build 26300, de-DE), 2560×1440 at 125% plus a 1920×1080 second screen, position = "bottom", Keep the dock visible, hide_taskbar = true. Wisp was started repeatedly (quit through WM_APP + 4, 4 s pause). A probe recorded when Explorer's taskbars were last visible, how many watchdogs started and how long the launcher window took to answer WM_NULL.

Normal conditions:

Build	Starts	Controller dropped	Taskbar last visible
v0.5.0 release	20	in 2 starts	~0.85 s; 3.8 s and 6.6 s in those 2
this branch	8	0	0.79–0.90 s

Under load (an out-of-process WinEvent hook on Explorer's show, hide and move events, which makes the first-hide failure happen in almost every start), both builds with the same tracing:

Build	Starts	Controller dropped	Taskbar last visible	Hidden after 11 s
main	10	37 times	median 9.4 s	2 of 10
this branch	10	0	median 0.86 s, max 0.89 s	10 of 10

On this branch the first reapply still fails 1–2 times per start under load, but the show hook hides the taskbar right after.

Performance
Startup: the taskbar is hidden at the same time as before when nothing goes wrong (0.79–0.90 s vs 0.74–0.99 s), and much sooner when the first hide fails (see above). The longest wait for the launcher's UI thread during startup is unchanged (250–330 ms in both builds; it comes from the existing synchronous ABM_SETSTATE and ShowWindow calls). Drawing, the dock and the launcher are not touched. measure-perf.ps1 runs the demo with hide_taskbar = false, so it doesn't exercise this code.

Not tested
Windows 10, a single screen (the failure I traced involved the second screen's taskbar), virtual desktops, and Explorer restarting while Wisp starts.

Fixes #28

• I understand every line of this change and tested a build of it.
• fmt, both clippy runs and the tests pass. fmt and both clippy runs pass. cargo test fails the two tests from Time search misses English city names on non-English Windows #26 on my German Windows, the same as on main.
• CHANGELOG.md has an entry under Unreleased, or this has nothing users notice.

🤖 Generated with Claude Code