docs: avoid mentioning blocking the event loop in async implementation

I think I was conflating a few different things when writing about avoiding
blocking the event loop as a reason for using threads in the async
implementation.

The reasoning for using threads is more:

- async_stream_zip takes async iterables
- which means if delegating to stream_zip, it would need to call async
  functions like anext or __anext__ from sync functions, and wait for them to
  complete.
- there is only really one choice for this that works/avoids deadlock:
  run_coroutine_threadsafe.
- which means this call must be in a different thread

README.md

@@ -29,7 +29,7 @@ In addition to being memory efficient (with some [limitations](https://stream-zi
 
 - By default stores modification time as an extended timestamp. An extended timestamp is a more accurate timestamp than the original ZIP format allows
 
-- Provides an async interface (that uses threads under the hood to share code with the sync interface without blocking the event loop)
+- Provides an async interface (that uses threads under the hood)
 
 <!-- --8<-- [end:features] -->
 

docs/features.md

@@ -20,4 +20,4 @@ In addition to being memory efficient (with some [limitations](/get-started/#lim
 
 - By default stores modification time as an extended timestamp. An extended timestamp is a more accurate timestamp than the original ZIP format allows
 
-- Provides an async interface (that uses threads under the hood to share code with the sync interface without blocking the event loop)
+- Provides an async interface  (that uses threads under the hood)