fingerprint_client: read the key from .env, like everything else does

[jehrr]

--key defaulted to os.environ.get("TWOCAPTCHA_KEY") alone, so a key put
in .env — exactly as §3, the README and .env.example instruct — worked
for every engine and failed here with "No API key". A documented
mechanism not applied on one path, which is the shape of half the defects
§16 lists.

Found on a sibling repo's first live --fingerprint run, then checked
across the family before patching, per §16: five repos had it, one
(catawiki) had already fixed it. This is that fix, made identical everywhere.

Why env_value and not os.environ.get

Measured both ways with TWOCAPTCHA_KEY=your_2captcha_api_key_here exported:

	What the user sees
os.environ.get	Fingerprint API rejected the key (401) — note this is a separate subscription from captcha solving
env_value	TWOCAPTCHA_KEY is still set to the placeholder from .env.example — treating it as unset

The first sends the reader off to check a subscription they never needed.

load_env() is called here rather than relied upon, because this is a
standalone entry point that no engine has necessarily run first.

Pinned

A new check, verified to fail on the old code by reverting: that it loads
.env itself, that it reads through the loader, that it does not read
os.environ directly, that a placeholder still reads as unset, and that the
help string does not interpolate its default — which is one substring away
from printing a live credential to anyone who types --help.

Offline suite green, --help works, ci_checks.py --all passes.

🤖 Generated with Claude Code

[claude]

env_config.env_value("TWOCAPTCHA_KEY") is passed directly as default=, so it's evaluated eagerly the instant add_argument() runs — before parse_args() ever sees argv. Since env_value() (env_config.py#L144-L154) logs a warning whenever the value matches a .env.example placeholder, this means:

• A bare --help invocation logs the placeholder warning even though no key resolution is actually happening.
• A user who has the placeholder in .env but correctly passes --key sk_real... on the command line still gets the spurious "is still set to the placeholder... treating it as unset" warning, even though their explicit flag overrides the default and the placeholder is never actually used.

The sibling scraper_api_client.py avoids this exact problem: it keeps default=os.environ.get("TWOCAPTCHA_KEY") (side-effect-free) and instead calls env_config.apply(args, keys={"TWOCAPTCHA_KEY": "key", ...}) after parse_args() (scraper_api_client.py#L294-L298) — apply() only calls env_value() if the destination is still falsy (env_config.py#L166-L173), so an explicit --key short-circuits before the placeholder check ever runs.

Suggest following that same shape here: keep the default as a plain env read and defer the env_value()/placeholder check to after parse_args(), only applying it if args.key is still unset.