fix: pass Impersonate option to extractor HTTP client

[eagle1maledetto]

Summary

The Impersonate field from the extractor YAML configuration is not forwarded to NewHTTPClientOptions when constructing the ExtractorContext in FromURL() (internal/extractors/util.go).

This means that even when an extractor has impersonate: true set in its configuration, the HTTP client is always created with Impersonate: false. The NewChromeClient() function — which provides Chrome TLS fingerprint impersonation to bypass JA3/JA4 detection — is never invoked.

Root cause

In internal/extractors/util.go, the NewHTTPClientOptions struct is populated with all config fields (Cookies, EdgeProxy, DownloadProxy, Proxy, DisableProxy) except Impersonate. This field was likely missed when the impersonation feature was originally added in commit 3b625c8.

Fix

A single line addition that passes cfg.Impersonate through to NewHTTPClientOptions, consistent with how all other config fields are already handled:

Impersonate:   cfg.Impersonate,

Impact

• Before: TLS impersonation was silently disabled for all extractors, regardless of configuration.
• After: Extractors with impersonate: true in their YAML config will correctly use NewChromeClient(), which sets Chrome-like cipher suites, TLS versions, and curve preferences.

This is critical for extractors targeting services that perform TLS fingerprinting (e.g., Facebook, Instagram).

Compliance

• Follows existing code conventions (field alignment, struct population pattern)
• No new dependencies
• No breaking changes — extractors without impersonate: true are unaffected
• Commit message follows the project's Conventional Commits style (fix: ...)