fix(client): reopen a closed client on use instead of raising ClientClosed

[thomasht86]

Restores compatibility with every released pyvespa, which 0.7.0 and 0.7.1 broke (see pyvespa#1347). Intended for 0.7.2, after which 0.7.0 and 0.7.1 should be yanked on PyPI.

Problem

0.7.0 made close() release the connection pool and turned use after close into ClientClosed. Vespa.visit() and Vespa.query(streaming=True) return lazy generators from inside a with VespaSync(...) block, so every released pyvespa consumes them after the client is closed. That worked for a year because close() was a no-op. Published pyvespa releases allow any httpr>=0.4.0, so only httpr can fix the field.

Change

A request on a closed client now reopens it (requests.Session semantics):

• RClient::begin_request rebuilds the reqwest::Client from the stored ClientConfig with a fresh CancellationToken (the old one was cancelled by close()), installs it via the new ClientState::reopen(), and emits httpr.ClientReopenedWarning, a ResourceWarning subclass: silent for end users, shown in test runs, and warnings.simplefilter("error", httpr.ClientReopenedWarning) restores httpx's strict behaviour.
• close() still releases the pool immediately; the lifecycle fix from close() / aclose() / __exit__ are no-ops — connections never released #88 is intact. is_closed is true from close() until the next request.
• Headers, params, auth, proxy and timeout live on RClient and carry over; the rebuilt client starts with an empty cookie store.
• client.proxy = ... on a closed client records the proxy for the rebuild instead of raising.
• AsyncClient creates its thread pool on demand and drops it on close, so a reopened client gets a new one. An open stream keeps reading after aclose() since it holds its own pool handle.
• ClientClosed stays exported (still a RuntimeError) but is only raised if a close() races the reopen itself.

Downstream CI job

New downstream-pyvespa job in CI.yml: checks out pyvespa master, installs it with [unittest], swaps in the wheel built from the PR with --no-deps, and runs pyvespa's unit suite. Runs on PRs, main and tags.

Verification

• httpr unit suite: 240 passed, 2 skipped. ruff, mypy, cargo fmt, clippy clean.
• pyvespa origin/master unit suite against this wheel, with -W error::httpr.ClientReopenedWarning: 693 passed, 140 subtests.
• pyvespa origin/master Docker integration tests that use visit() (the ones that fail on 0.7.1): running, results in a comment below.

🤖 Generated with Claude Code

[thomasht86]

Downstream verification against unmodified pyvespa origin/master (i.e. without pyvespa#1347), wheel built from this branch:

Suite	Result
tests/unit with -W error::httpr.ClientReopenedWarning	693 passed, 140 subtests
tests/integration/test_integration_docker.py -k "test_retries_sync or test_document_expiry" (both drive app.visit())	2 passed in 93 s

Each Docker test emitted ClientReopenedWarning exactly once, from Vespa.visit() consuming its generator after the with VespaSync block closed the client. That is the path that raises ClientClosed on 0.7.1, so the reopen is doing what it is for. The unit suite stays silent under the warning-as-error filter because it mocks the client.

[codspeed]

Merging this PR will not alter performance

✅ 35 untouched benchmarks

---

_{Comparing fix/reopen-after-close (1728606) with main (10d49a2)}