perf: move OS theme detection to a background task

[lklimek]

User Story

As a user running Dash Evo Tool on Linux, I want the app to remain responsive when the OS theme detection is slow, so that I don't experience frame drops or UI stutter every 2 seconds.

Problem

dark_light::detect() queries the XDG Desktop Portal via D-Bus, which has a hardcoded ~100ms timeout. On systems without a portal daemon (minimal WMs, headless setups, some Wayland compositors), this blocks the main UI thread every 2 seconds during the theme polling cycle.

Currently the timeout is handled gracefully (previous theme is preserved, error is logged at debug level), but the blocking call can still cause frame drops.

Proposed Solution

Move theme detection off the main thread:

1. Use tokio::task::spawn_blocking (or a dedicated thread) to run dark_light::detect() asynchronously
2. Send the result back via a channel or shared atomic state
3. The main update() loop reads the latest detected theme without blocking

This follows the existing app task pattern — the detection becomes a lightweight background poll rather than a synchronous call in the frame loop.

Context

• dark_light v2.0.0 is the latest version; no upstream fix for the timeout
• The timeout is a known issue: winit#2893, egui#3061
• Related PR: fix(ui): throttle system theme detection to prevent white flash #781 (throttle + cache theme detection)

_{🤖 Co-authored by Claudius the Magnificent AI Agent}