Fixes: preserve taskbar monitor selection + widget vanishing when start menu opens

[andreescocard]

No description provided.

[androosio]

Nice, I landed on the same device-name approach independently while looking at #43, so I can confirm the core mechanism is sound (and nice work on the start menu issue, I totally missed that!).

I closed my PR (#48) in favor of yours as you got there first. A few suggestions from my PR you might consider folding in:

1. Fall back to the primary monitor instead of the geometric index

When the remembered device isn't found (first run, monitor swapped/renamed), attach_to_taskbar currently falls back to requested_index.min(len-1). Since find_taskbars() sorts by rect.top first, index 0 is the topmost taskbar (which on a setup with a vertical secondary monitor is often that secondary screen, i.e. the exact symptom from #43). Anchoring the fallback to the primary monitor avoids re-triggering the bug in that path:

// in TaskbarWindow: also capture the primary flag
// (MONITORINFO.dwFlags & MONITORINFOF_PRIMARY) != 0  → pub is_primary: bool

let index = requested_device
    .filter(|d| !d.is_empty())
    .and_then(|device| taskbars.iter().position(|t| t.device == device))
    .or_else(|| taskbars.iter().position(|t| t.is_primary))   // <- primary before index
    .unwrap_or_else(|| requested_index.min(taskbars.len().saturating_sub(1)));

2. Briefly wait for the remembered monitor's taskbar on startup

A short retry in attach_to_taskbar (e.g., up to ~2s, 200 ms ticks) when requested_device is set but not yet present makes restarts stick to the right monitor.

3. (Optional UX) Let the user pick the monitor explicitly

A small Settings > Monitor submenu listing each detected taskbar (primary marked) is a nice complement as it gives users a direct way to move the widget without dragging, and writes the same taskbar_device. Pairs well with having Reset position, also clear the stored device so it falls back to primary, as an escape hatch if it ever gets stuck.