Add native macOS duplex stream

CHANGELOG.md

@@ -11,6 +11,8 @@ public APIs may still change while the backend design stabilizes.
 
 - Added the public `DuplexStream` API contract for backend-level full-duplex
   capture and playback.
+- Added native macOS `DuplexStream` support backed by Core Audio input and
+  output queues owned by one native stream object.
 
 ## [0.2.0a3] - 2026-06-12
 

README.md

@@ -57,8 +57,8 @@ Use blocking helpers when callers need complete buffer transfer:
 - `InputStream.read_exactly(frame_count, timeout=None)`: wait until exactly the
   requested number of frames has been captured
 
-Full-duplex capture/playback is exposed as `DuplexStream`. The public API is in
-place, but native backend implementations are still under development.
+Full-duplex capture/playback is exposed as `DuplexStream`. Native macOS and
+Linux support is available.
 
 Lifecycle semantics:
 

docs/architecture.md

@@ -42,7 +42,9 @@ conveniences layered on top of those primitives.
 Full-duplex support is modeled as a backend-level `DuplexStream`, not as a
 Python wrapper around one `OutputStream` and one `InputStream`. Backends should
 use a single native duplex callback where available so capture and playback share
-one scheduling clock.
+one scheduling clock. The current macOS implementation owns both native Core
+Audio queues inside one native stream object. The Linux miniaudio implementation
+uses one native duplex device callback.
 
 Stream statistics distinguish queue state from hardware behavior. `queued_frames`
 and `queued_latency` describe the native ring buffer. `hardware_latency`