fix(macos): handle nil URL/method/header values in url_scheme_handler

[TranscriptionFactory]

Summary

url_scheme_handler::start_task unwraps four values that WebKit may legitimately return as nil:

• request.URL() (L91)
• url.absoluteString() (L93)
• request.HTTPMethod() (L99)
• all_headers.valueForKey(&current_header) (L130)

When any of these is nil, the unwrap aborts inside an Objective-C callback invoked across the FFI boundary, producing a SIGABRT with no recovery path. In our downstream Tauri app, opening a graph view reliably triggered this — WebKit was synthesizing a custom-scheme request without a URL on the navigation path, and the unwrap turned an Option into a process abort.

Change

Each of the four unwrap()s becomes a defensive branch:

• Nil URL / absoluteString: emit a tracing::warn! (gated on the tracing feature) and return from the task handler, dropping the malformed request rather than crashing the process.
• Nil HTTPMethod: warn and fall back to "GET", which matches NSURLRequest's default.
• Nil header value: skip that header inside the loop instead of aborting the whole request.

A short comment near the URL handling explains the rationale.

Behavior

For well-formed requests (the common case), behavior is unchanged. For malformed requests, the task either completes with a degraded method/header set or terminates early, instead of aborting the process.

Test plan

• cargo check clean on dev profile (macOS arm64) on this branch.
• cargo fmt applied.
• Verified downstream (Tauri 2.11 + Wry 0.55.1 patched with this change) that the SIGABRT on graph-view open no longer occurs; the same flow on unpatched Wry 0.55.1 reliably reproduces the crash.

I'm happy to add a unit test if there's an established pattern for mocking a WKURLSchemeTask with nil values, but I didn't find one in the existing src/wkwebview/ tests.