feat(desktop): expose Config::with_background_throttling to opt out of WKWebView WebContent suspension

[goosewobbler]

Closes #5586.

What

Adds Config::with_background_throttling(BackgroundThrottlingPolicy) to dioxus-desktop, surfacing the policy that wry already supports via WebViewBuilder::with_background_throttling. Forwards the value to the WebView at construction.

use dioxus::desktop::wry::BackgroundThrottlingPolicy;

let config = dioxus::desktop::Config::new()
    .with_background_throttling(BackgroundThrottlingPolicy::Disabled);

Three variants from wry:

• Disabled — never throttle.
• Suspend — fully suspend tasks when the view isn't in a window (current implicit default).
• Throttle — limit rather than suspend.

The setting is applied at WebView creation; non-Apple platforms ignore it in wry today, so this is effectively a macOS opt-out.

Why

On macOS, WKWebView aggressively suspends the WebContent process (the process running page JS) when the host window isn't visible/focused, freezing all JS timers, fetches, and event handlers. On a headless host — CI runner, hidden window, no focus — that suspension is permanent.

Without this knob, there's no way for a Dioxus app to opt out from Rust-side config. The workarounds I tried first (caffeinate -dims, NSAppSleepDisabled=YES, JS-side AudioContext/muted HTMLAudioElement keepalive) all failed because the throttling is WebKit-internal, not OS-level App Nap. Calling WebViewBuilder::with_background_throttling(Disabled) at construction was the only fix.

Concrete cases this unblocks:

• Automation / E2E testing on macOS CI. This came up building @wdio/dioxus-service — an embedded WebDriver server inside the app process polls the webview over a wdio:// IPC channel, and the polling loop froze within seconds on macOS-ARM GitHub Actions runners. The same suite passes interactively on macOS and on Linux/Windows CI.
• System-tray apps with a hidden main window doing background work in the webview.
• Background renderers / streaming UIs that should keep ticking off-screen.

See #5586 for the broader motivation discussion.

Implementation

Mirrors the existing pattern for other forwarded wry attributes (with_background_color, with_data_directory, etc.):

1. Config gets background_throttling: Option<BackgroundThrottlingPolicy> (default None).
2. New builder method Config::with_background_throttling.
3. webview.rs forwards the value to WebViewBuilder::with_background_throttling when set.

None preserves current behaviour exactly — the attribute is only set if the app calls the new builder method.

Test plan

• cargo check -p dioxus-desktop clean.
• Verified end-to-end on macOS-ARM CI with a downstream consumer (@wdio/dioxus-service): full E2E suite that previously timed out within the first spec now passes consistently across runs (reference run — once we wired this API up to set Disabled under automation, the polling-loop hang disappeared).
• No new unit/integration tests added — the call is a pass-through to a wry method that's already tested upstream. Happy to add a smoke test if you'd like one (suggestions on placement welcome — I didn't see an obvious existing pattern for Config builder methods).

Notes

• wry::BackgroundThrottlingPolicy is reachable via the existing pub use wry; line in dioxus_desktop::lib, so consumers can use dioxus::desktop::wry::BackgroundThrottlingPolicy without adding wry as a direct dep.
• Considered naming the method with_inactive_scheduling_policy to match Apple's docs term, but kept it aligned with wry's with_background_throttling for consistency with the upstream API.

[goosewobbler]

Note for reviewers: the failing Check | Minimum dependency versions job is unrelated to this PR's changes — it's the upstream rhai 1.24.0 / 1.25.0 min-versions issue that @Booyaka101 has already analysed in #5583. Same failure on current main (run 26470310750), and our PR added zero deps or version constraints (only packages/desktop/src/{config.rs,webview.rs}). Not addressable from this diff.