chore: fix new clippy warnings (derive default)

[tomerqodo]

Benchmark PR from qodo-benchmark#150

[tomerqodo]

augment review

[tomerqodo]

augment review

[augmentcode]

🤖 Augment PR Summary

Summary: This PR updates several enums across the codebase to satisfy new clippy warnings by switching from manual Default impls to #[derive(Default)] + #[default] variants.

Changes:

• Replaced hand-written Default implementations with derived defaults in CLI/runtime/utils config enums (Windows updater mode, device event filter, bundle target, installer modes, pattern kind, title bar style, etc.).
• Consolidated the MissingBundleTypeVar bundler error into a single enum variant using cfg_attr to select the appropriate platform-specific thiserror::error message.
• Updated tray mouse enums to derive Default and introduced a TrayIconEvent::new_click helper constructor for creating mock/canned click events.

Technical Notes: The intent appears to be behavior-preserving (defaults remain the same), while reducing duplicated boilerplate and addressing lint warnings.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

The From<tray_icon::MouseButtonState> conversion now inverts Up/Down, which changes the meaning of button_state for all emitted tray click events and can break handlers that match on the previous values. If this wasn’t intentional, consider keeping a 1:1 mapping (or updating docs/examples/tests to reflect the new semantics).

_{🤖 Was this useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

The From<tray_icon::MouseButtonState> mapping now inverts Up/Down (Up -> Down, Down -> Up), which looks like a behavioral change that could break click handling (e.g., examples match on MouseButtonState::Up). Was this inversion intentional, and if so is the public Up/Down semantics meant to differ from tray_icon?

_{🤖 Was this useful? React with 👍 or 👎}

[augmentcode]

TrayIconEvent::new_click constructs rect: Rect { position: PhysicalPosition {..}, size: PhysicalSize {..} }, but Rect elsewhere is populated via .into() from tray_icon::Rect (and uses Position/Size fields). This may yield an invalid/incorrect rect value (or at least an inconsistent representation) for serialization/consumers.

_{🤖 Was this useful? React with 👍 or 👎}