fix(fingerprints): fallback gracefully when browserforge raises ValueError on unsupported Chrome versions

[shdwkl]

Description

When chromium_version or chrome_version hardcoded in scrapling/engines/toolbelt/fingerprints.py exceeds the maximum version supported in browserforge's header dataset (apify-fingerprint-datapoints), HeaderGenerator.generate() raises a ValueError:

ValueError: No headers based on this input can be generated. Please relax or change some of the requirements you specified.

Because generate_headers(browser_mode=False) is executed at module import time in scrapling/engines/_browsers/_config_tools.py, this ValueError crashes any application importing scrapling at boot time.

Fix

• Wrapped HeaderGenerator(...).generate() in a try...except ValueError block in generate_headers().
• If the exact min_version=ver, max_version=ver constraint is not present in browserforge's dataset, it falls back to unconstrained browser definitions.
• Ensures generate_headers() always returns valid headers without crashing.

[Copilot]

Pull request overview

This PR prevents scrapling from crashing at import time when browserforge can’t generate headers for a hardcoded (too-new) Chrome/Chromium version by adding a graceful fallback path in the header generation helper.

Changes:

• Wrap HeaderGenerator(...).generate() in try/except ValueError inside generate_headers().
• On ValueError, retry header generation with unconstrained browser definitions (no explicit version constraints).
• Preserve existing behavior differences between “browser mode” vs non-browser mode while ensuring import-time header generation doesn’t fail.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[D4Vinci]

Nice idea, buddy, but it's not the optimal solution. I will make scrapling access Apify's neural network right away to skip the generation part, so it's faster, and also I want it now to be not limited to desktop devices only.

This whole issue was caused by an issue with apify-fingerprint-datapoints version 0.14.0, but they have now released version 0.15.0, which fixed it. Anyway, I will make sure this doesn't happen again