docs: correct the CurlCffi redirect-history claim

curl_cffi never populates Response.history (it follows redirects in the native curl layer
and surfaces only the final URL/status), so the v0.1.7 claim that resp.history shows 'the
real hops on either backend' was false for CurlCffi - resp.history/redirect_chain are []
there even after a redirect. README + changelog now document this curl_cffi limitation
instead. Noble threads whatever noble_tls records. No code change (the adapter is correct;
curl_cffi just has no data to map).

Signed-off-by: disqualifier <dev@disqualifier.me>

README.md

@@ -199,11 +199,15 @@ cookie store (both expose a `requests`-style `session.cookies` with `set()` /
 `aioweb.ExtendedSession`, not just `_cookies_for_url()` (used by `preview()`).
 
 `resp.history` / `resp.redirect_chain` (`[(status, url), ...]`) and `resp.is_redirect`
-are also threaded through on both backends: `CurlCffi.raw_request` maps curl_cffi's
+are threaded through from whatever redirect history the backend exposes. **Caveat — the
-`Response.history` (`list[dict]`) and `Noble.raw_request` maps noble_tls's
+CurlCffi backend has no per-hop history:** `curl_cffi` follows redirects internally in the
-`list[Response]` into aioweb's `(status, url)` tuple shape, so `debug=True`'s "redirect
+native curl layer and surfaces only the final URL/status, leaving `Response.history` an
-chain:" log line and any caller reading `resp.history` after a redirecting request see
+empty list (it never populates it). So on `CurlCffi`, `resp.history`/`resp.redirect_chain`
-the real hops on either backend, matching the base `aioweb.ExtendedSession` behavior.
+are `[]` and `resp.is_redirect` reflects only the final response, even after a redirect —
+this is a `curl_cffi` limitation, not a bug here, and it differs from the base aiohttp
+`ExtendedSession` (which does record the hops). The `Noble` backend threads whatever
+`noble_tls` exposes as its per-response history. If you need the redirect chain, use the
+base backend or read the final URL.
 
 ## Honesty note
 
@@ -221,14 +225,15 @@ are separate signals. Use this as one component, not a complete anti-bot solutio
 
 ### v0.1.7
 
-- **Both backends now thread redirect history.** `CurlCffi.raw_request` and
+- **Backends thread whatever redirect history the client exposes.** `CurlCffi.raw_request`
-  `Noble.raw_request` built their `Response` without `history=`, so
+  and `Noble.raw_request` built their `Response` without `history=`, so
-  `resp.history`/`resp.redirect_chain`/`resp.is_redirect`-after-follow were
+  `resp.history`/`resp.redirect_chain`/`resp.is_redirect`-after-follow were always empty
-  always empty and aioweb's own `debug=True` "redirect chain:" log line was
+  and aioweb's own `debug=True` "redirect chain:" log line was dead on both TLS backends.
-  permanently dead on both TLS backends, despite the "inherits every aioweb
+  Each backend now maps its client's history into aioweb's `(status, url)` tuple shape.
-  feature unchanged" claim. Each backend's native history (curl_cffi
+  **Caveat:** `curl_cffi` never populates `Response.history` (it follows redirects in the
-  `list[dict]`, noble_tls `list[Response]`) is now mapped into aioweb's
+  native curl layer and surfaces only the final URL/status), so on the `CurlCffi` backend
-  `(status, url)` tuple shape and passed through.
+  `resp.history` is `[]` even after a redirect — a `curl_cffi` limitation, not addressable
+  here. `Noble` passes through whatever `noble_tls` records.
 
 ## Versioning