SDK: safe request-path defaults for verify() (1s timeout + fail-closed)

[imxinchengyou]

What

verify() / verify_batch() are on the caller's request path, but the client
treated them like every other call: the 10s control-plane timeout, and an
exception on any failure. A slow or unreachable verifier stalled requests for up
to 10s and turned an outage into a hot-path exception. The docs already told
users to work around this by hand (timeout=1.0 + catch-and-fall-through) — this
makes the SDK default match that advice.

Changes

• verify_timeout (default 1.0), separate from timeout (still 10.0,
  used for feedback / fine-tune / monitoring). Applied per-request, so
  control-plane calls are unchanged.
• Fail-closed by default. On a timeout / connection error / 5xx, verify()
  logs a warning on the cacheverifier logger and returns a synthetic
  VerifyResult(degraded=True, approved=False) instead of raising — the caller
  falls through to their LLM exactly as on a cache miss. 4xx (bad key, bad
  request, rate limit) still raises CacheVerifierError.
• fail_open=True flips the degraded result to approved=True, for traffic
  where a stale-or-near-miss answer beats a regeneration.
• VerifyResult gains degraded: bool; model_version is "verify_unavailable"
  on a synthesized result.
• GPTCache adapter takes the same verify_timeout / fail_open; returns 0.0
  (don't reuse) on a verifier outage by default.

v0.2.0 → v0.3.0. New tests cover the tight timeout, fail-closed/open on
timeout + 5xx, 4xx still raising, and batch degrading every pair. ruff,
mypy cacheverifier, full pytest green locally.

Compat note

Callers that wrapped verify() in try/except CacheVerifierError for transport
failures will now instead see result.degraded is True — the except still
catches real 4xx. Behavior on success is unchanged.