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