(py) Browser-string match drift: 'chrome124' maps to chrome_125 in async but panics in sync client

[barjin]

🤖 Found by Claude ultrareview — automated high-effort code review. Please verify independently before acting.

Location: impit-python/src/async_client.rs:66 vs impit-python/src/client.rs:60

The browser-string → fingerprint match has drifted between the async and sync clients:

// async_client.rs
"chrome" | "chrome124" => builder.with_fingerprint(... chrome_125::fingerprint()),
...
"chrome125" => builder.with_fingerprint(... chrome_125::fingerprint()),

// client.rs
"chrome" | "chrome125" => builder.with_fingerprint(... chrome_125::fingerprint()),
...
_ => panic!("Unsupported browser"),

Impact:

• AsyncClient(browser="chrome124") silently returns a mislabeled chrome_125 fingerprint.
• Client(browser="chrome124") hits _ => panic!("Unsupported browser") and aborts across the FFI boundary instead of raising a catchable Python ValueError.

The two bindings disagree on which inputs are valid, and unknown browser strings crash the process rather than raising a Python exception.

This match (plus the verb-dispatch and ImpitError→code mappings) is hand-duplicated across all three bindings; the divergence above is a direct consequence. Consider moving the string→fingerprint resolution into the core impit crate (e.g. a TryFrom<&str>/fingerprint_by_name) so all bindings share one source of truth, and returning a proper error for unknown names instead of panicking.