docs: §6.3 — browser-direct is a watch-item (WebTransport vs WebRTC), relay-only today

Records the current state of iroh browser P2P: relay-only is the floor; the
credible future unlock is WebTransport + serverCertificateHashes (n0's preferred
path — they avoid WebRTC's heavy ICE/STUN/TURN model on purpose), roadmap with
no timeline. WebRTC exists only as a third-party community alpha
(iroh-webrtc-transport, unstable-custom-transports). Both land behind the same
endpoint.connect(), so it's free upside — track n0's WebTransport work, don't
design for browser-direct.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ARCHITECTURE.md

@@ -280,6 +280,15 @@ The hard networking kernel exists. To become a general substrate:
    "engine + `IrohTransport` only, `default-features=false`, `wasm32`." Cost:
    browser peers lean on the relay (no P2P offload) — trivial for clipboard,
    relay-carried for big files.
+   - **Browser-direct is a watch-item, not a dependency.** Relay-only is the
+     floor today. The *credible* path to browser P2P offload is **WebTransport
+     + `serverCertificateHashes`** (n0's preferred route — they deliberately
+     avoid WebRTC, whose ICE/STUN/TURN bundle is the stateful/expensive model
+     iroh exists to escape); it's roadmap, no timeline. **WebRTC** exists only as
+     a community alpha (`iroh-webrtc-transport`, third-party, on the experimental
+     `unstable-custom-transports` API) — long-shot. Both would arrive behind the
+     same `endpoint.connect()`, so it's zero-effort upside we wait for. Track
+     whether n0 ships WebTransport browser-direct from core; don't design for it.
 4. **Capabilities / permissions (target).** Multi-user needs object-capabilities
    (UCAN), not ACLs.
 5. **Persistence / offline-first (target).** Local store + sync-on-reconnect