docs: update README and design doc for 0.2.0 (add installation, fix require() example, document typed events)

Author: 1amageek

Package.resolved

@@ -10,6 +10,16 @@ The API should stay simple enough for application code to use without learning l
 
 See [Design Philosophy](docs/DESIGN_PHILOSOPHY.md) for the broader project context and design constraints.
 
+## Installation
+
+Add the package to your `Package.swift` dependencies:
+
+```swift
+.package(url: "https://github.com/1amageek/swift-peer-connectivity.git", from: "0.2.0")
+```
+
+The libp2p backends require swift-libp2p 0.2.0.
+
 ## Usage
 
 Create a session with an explicit backend, browse and advertise when the backend supports those roles, then join discovered peers.
@@ -24,7 +34,7 @@ let session = PeerConnectivitySession.multipeer(
     displayName: "Device A"
 )
 
-try await session.require([.nearbyDiscovery, .messageSend])
+try session.require([.nearbyDiscovery, .messageSend])
 try await session.startBrowsing()
 try await session.startAdvertising()
 
@@ -55,6 +65,12 @@ Multi-peer `send(_:to:[peers])` is exhaustive, not atomic: it attempts every pee
 and, if any fail, throws `PeerSendError` listing per-peer outcomes (which
 succeeded, which failed) instead of aborting on the first failure.
 
+`.error` carries a typed `PeerConnectivityErrorEvent` (operation, peer, and the
+underlying error) so a failure can be attributed rather than surfaced as a bare
+`Error`. Messages and resources use length-prefixed framing, so a truncated
+inbound transfer surfaces as a typed error instead of a silently incomplete
+payload, and inbound handlers apply an idle timeout.
+
 Use `join(_:)` for discovered peers. It uses endpoints for direct-connect backends and invitations for nearby-session backends. Use `connect(to:)`, `invite(_:context:timeout:)`, and `openChannel(to:protocol:)` when backend-specific behavior is intentional.
 
 `startBrowsing()` and `startAdvertising()` fail when the backend cannot control those roles separately. Use `start()` when the application intentionally wants the backend's complete configured lifecycle.
@@ -135,4 +151,6 @@ Use explicit factories so call sites choose the backend intentionally:
 - `PeerConnectivitySession.appleNetworkLibP2P(configuration:)`
 - `PeerConnectivitySession.multipeer(serviceType:displayName:)`
 
+`appleNetworkLibP2P(configuration:)` is throwing. When `enableBonjour` is set, it requires at least one listen address to announce; otherwise it throws `PeerConnectivityError.listenAddressRequired` rather than advertising `.bonjourDiscovery` it cannot honor.
+
 Automatic backend selection is intentionally omitted from the initial API surface.

README.md

@@ -164,7 +164,7 @@ let session = PeerConnectivitySession.multipeer(
     displayName: "Robot A"
 )
 
-try await session.require([.nearbyDiscovery, .messageSend])
+try session.require([.nearbyDiscovery, .messageSend])
 try await session.startBrowsing()
 try await session.startAdvertising()
 
@@ -189,11 +189,11 @@ each access. Subscribe before `start()` so no early events are missed.
 For cross-platform Robot communication, the app should choose a libp2p-compatible backend explicitly:
 
 ```swift
-let session = try await PeerConnectivitySession.appleNetworkLibP2P(
+let session = try PeerConnectivitySession.appleNetworkLibP2P(
     configuration: configuration
 )
 
-try await session.require([.libp2pInterop, .streamMultiplexing])
+try session.require([.libp2pInterop, .streamMultiplexing])
 ```
 
 The important distinction is intentional backend choice with a common app-facing workflow.