Update DocC for suspending authorize, connect error, and bounded discoveries

- GettingStarted: authorizeBluetooth() now suspends until the user responds and
  returns only when authorized (and is cancellable) — document the new behavior in
  place of the old "no-op" note.
- GettingStarted: the connect(to:) example now also handles
  PeripheralError.bluetoothUnavailable.
- GettingStarted & Concurrency: note that the peripheralDiscoveries feed is bounded
  (drops the oldest pending advertisements under backpressure).

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

Author: itsniper

Sources/ReliaBLE/Documentation.docc/GettingStarted.md

@@ -69,7 +69,9 @@ iOS requires permission from the user for BLE access. To set this up in your pro
    ```
    The current state is replayed as the stream's first element, so a new subscriber immediately observes the latest state.
 
-Note: The authorization prompt will only appear once. It is safe to call `ReliaBLEManager.authorizeBluetooth()` multiple times. If the user already granted permission it will be a no-op. If the user denies permission, they'll need to enable it manually through the Settings app.
+Note: When authorization has not yet been determined, `ReliaBLEManager.authorizeBluetooth()` presents the system prompt and **suspends until the user responds** — it returns normally only once access is granted, and throws ``AuthorizationError`` if the user denies or access is restricted. A successful return therefore means Bluetooth is authorized. Cancelling the calling task unblocks the suspension with a `CancellationError`.
+
+The prompt only appears once, and it is safe to call the method multiple times: if the user already granted permission the call returns immediately; if they denied it, they'll need to re-enable access through the Settings app.
 
 ## Scanning for Peripherals
 
@@ -125,7 +127,7 @@ While scanning, ReliaBLE surfaces results two ways:
 - ``ReliaBLEManager/peripheralDiscoveries`` emits a lightweight ``PeripheralDiscoveryEvent`` for every advertisement received — useful when you need to process individual advertisement packets.
 - ``ReliaBLEManager/discoveredPeripherals`` emits the current de-duplicated list of ``Peripheral`` values each time it changes.
 
-Both are `AsyncStream`s. Each property access returns a *fresh, independent* stream, so multiple subscribers are supported by design — consume each with `for await`, typically inside a SwiftUI `.task { … }` (which cancels the loop automatically when the view disappears). ``ReliaBLEManager/state`` and ``ReliaBLEManager/discoveredPeripherals`` replay their latest value to every new subscriber; ``ReliaBLEManager/peripheralDiscoveries`` does **not** replay, so subscribe before you start scanning to avoid missing early advertisements.
+Both are `AsyncStream`s. Each property access returns a *fresh, independent* stream, so multiple subscribers are supported by design — consume each with `for await`, typically inside a SwiftUI `.task { … }` (which cancels the loop automatically when the view disappears). ``ReliaBLEManager/state`` and ``ReliaBLEManager/discoveredPeripherals`` replay their latest value to every new subscriber; ``ReliaBLEManager/peripheralDiscoveries`` does **not** replay, so subscribe before you start scanning to avoid missing early advertisements. The discoveries feed is also bounded, so a subscriber that consumes slower than advertisements arrive drops the oldest pending events rather than growing memory without bound.
 
 A ``Peripheral`` is an immutable, `Sendable` value snapshot: it carries the peripheral's ``Peripheral/id``, ``Peripheral/name``, ``Peripheral/rssi``, ``Peripheral/lastSeen``, and a strongly-typed ``AdvertisementData`` rather than a raw `[String: Any]` dictionary. Because it is a value type, it is safe to hand directly to your UI.
 
@@ -149,6 +151,9 @@ do {
 } catch PeripheralError.notFound {
     // The snapshot is stale — its underlying peripheral reference was invalidated
     // (for example, after a Bluetooth reset). Re-scan to rediscover it.
+} catch PeripheralError.bluetoothUnavailable {
+    // Bluetooth has not been set up yet (for example, not authorized). Authorize and wait
+    // for the `.ready` state before retrying.
 }
 ```
 

Sources/ReliaBLE/Documentation.docc/Topics/Concurrency.md

@@ -71,7 +71,9 @@ Replay semantics differ per stream:
 - ``ReliaBLEManager/discoveredPeripherals`` — replays the **latest** value to new
   subscribers (`.bufferingNewest(1)`).
 - ``ReliaBLEManager/peripheralDiscoveries`` — does **not** replay; a new
-  subscriber only receives discoveries that occur after it begins iterating.
+  subscriber only receives discoveries that occur after it begins iterating. Its
+  buffer is bounded (`.bufferingNewest`), so a slow subscriber drops the oldest
+  pending advertisements rather than growing memory without bound.
 
 Because each call returns an independent stream, multiple parts of your app can
 observe the same surface concurrently without interfering with one another.