feat: configurable timeout + auto-retry for headless login

[okuegow]

The Bluelink backend often needs a warm-up on the first call after a quiet period (cold session); curl_cffi's default ~10s timeout then surfaces as a hard failure. Reported by Genesis users in evcc-io/evcc#30223 but applies to all brands — Kia/Hyundai owners with a car that sleeps will hit the same cold-call symptom.

What changes

• headless_login() gains a timeout=30 keyword argument and passes it to all four HTTP calls (authorize / certs / signin / token-exchange). Previous behaviour relied on curl_cffi's ~10s default.
• main() exposes two new CLI flags:
  • --timeout <seconds> — default 30, bump to 60+ on slow networks.
  • --retries <n> — default 1 (= one retry after a failure, two attempts total). Use 0 to disable retries.
• main() wraps headless_login() in a retry loop that only catches transport errors (curl_cffi.requests.exceptions.RequestException / OSError). Auth failures, missing code in redirect, HTTP-status problems etc. still sys.exit from inside headless_login(), so retries do not paper over real errors.

Why these defaults

• Default timeout 30s balances cold-backend coverage against not making auth failures hang too long. Users with reliable networks can lower it; users on slow setups can raise it.
• One automatic retry is enough to handle the common cold-call pattern (second call is fast because the backend session is warm). More retries are user-configurable.

Compatibility

• Browser flow unchanged.
• All new params have defaults; existing callers / pipelines see no API break.
• Tested locally on a Genesis EU account (1 attempt, 1 retry, default timeout); auth succeeded on first attempt under normal conditions.

Independent of #9 (Genesis brand) — they don't touch the same lines.