fix(macos): move Launch at Login operations off the UI thread

[nalapon]

Why

Hex asks macOS for the Launch at Login status every 500 ms. These calls currently run on the same thread that handles the UI, so it has to wait for macOS to respond before continuing.

I moved this work to a separate thread so the UI does not need to wait for those calls.

What Changes

As suggested in #89, this uses one long-lived worker with a request channel instead of creating a new thread for each request.

The worker handles status checks, enabling/disabling Launch at Login, and opening Login Items settings. If it is busy, repeated checks are skipped and only the latest pending user action is kept.

macOS still owns the setting. Hex reads the response and updates the toggle; it does not save another copy of the setting.

Closing Settings stops the worker. Opening it again creates a new one.

Verification

• Debug: 486 tests passed, 12 ignored.
• Release: 485 tests passed, 12 ignored.
• All 12 keyboard-layout scenarios passed in both profiles.
• Formatting, strict debug Clippy, and diff checks passed.
• Tested enabling/disabling, repeated clicks, and changes made from macOS Settings.
• Checked that closing Settings stops the worker and that Cmd+Q and Quit HEX stop the app.
• A five-second profile showed SMAppService calls on the worker and none on the UI thread. I have not measured a responsiveness improvement.

The manual checks used an ad-hoc signed temporary app. Developer ID signed distribution behavior and native approval/error transitions remain unverified.

[kitlangton]

Thanks, merged. The single-worker ownership, bounded channels, pending-action coalescing, and nonblocking close behavior look good. After building the command SDK prerequisite, I verified all 486 Rust tests and all 12 keyboard-layout scenarios, plus strict all-target/all-feature Clippy, formatting, and whitespace checks. I did not repeat the native signed-app login-item smoke test.