Use native iroh-blobs for CAS fetches

docs/architecture.md

@@ -31,17 +31,21 @@ uses Iroh's default relay policy; local-only/offline development can set
 The native module-backend crates for the intended CAS, KV, and pubsub
 replacements now compile against the same endpoint generation:
 `iroh-blobs 0.97.0`, `iroh-docs 0.95.0`, and `iroh-gossip 0.95.0`. `geth-iroh`
-exposes their native ALPNs so module migrations can register handlers without
-creating a second daemon endpoint. `geth status` reports these backends as
-ready to wire. The module implementations still use explicit bootstrap
-control-ALPN paths until each module is migrated to its native protocol.
+exposes their native ALPNs without creating a second daemon endpoint. CAS now
+registers an `iroh-blobs` provider handler on `/iroh-bytes/4`; local CAS writes
+are mirrored into the native blob store, and remote `geth cas fetch` performs a
+geth control-ALPN authorization preflight before transferring payload bytes over
+`iroh-blobs`. `geth status` reports these native backend libraries. KV and
+pubsub still use explicit documented bootstrap equivalents until each module is
+migrated to its native protocol.
 
 Module ALPNs are registered through `geth-iroh`'s protocol router scaffold. The
 router owns the default protocol descriptors, rejects duplicate ALPN
 registrations, and returns explicit unknown-ALPN errors. The current daemon
-accept loop dispatches geth control, pipe, and SSH-proxy streams directly; the
-next backend migrations should attach iroh-blobs, iroh-docs, and iroh-gossip
-handlers to the same endpoint instead of creating parallel endpoints.
+accept loop dispatches geth control, pipe, SSH-proxy, and native CAS blob
+streams directly; the next backend migrations should attach iroh-docs and
+iroh-gossip handlers to the same endpoint instead of creating parallel
+endpoints.
 
 The target product should use Iroh relay support for practical internet
 connectivity and mDNS/LAN discovery for local networks. These are connectivity