fix(cdp): gate Target.createTarget file:// like Page.navigate

GHSA-q55h-vfv9-qcr5 patched Page.navigate to refuse file:// URLs
unless --allow-file-access was set, but Target.createTarget accepted
the same scheme and called page.navigate(url) directly, bypassing
the policy. A CDP client could call Target.createTarget {url: file://...}
then Runtime.evaluate to read document.body.textContent and recover
arbitrary local files.

Apply the same gate at the Target.createTarget entrypoint. Pull
the file-scheme detector into a shared util module so both domains
stay in lock-step instead of one drifting from the other.

Verified blocked vs the unpatched build (pr69):
  - Patched: Target.createTarget {url: file:///tmp/secret} errors
    "Target.createTarget to file:// is disabled. ..." before any
    navigation runs.
  - Unpatched: same call returns the file contents via
    Runtime.evaluate {expression: "document.body.textContent"}.

crates/obscura-cdp/src/domains/page.rs

@@ -3,14 +3,7 @@ use serde_json::{json, Value};
 
 use crate::dispatch::CdpContext;
 use crate::types::CdpEvent;
-
-fn url_is_file_scheme(raw: &str) -> bool {
-    url::Url::parse(raw)
-        .map(|u| u.scheme().eq_ignore_ascii_case("file"))
-        .unwrap_or_else(|_| {
-            raw.trim_start().to_ascii_lowercase().starts_with("file:")
-        })
-}
+use crate::util::url_is_file_scheme;
 
 pub async fn handle(
     method: &str,