docs: fix collision-prone streamSwarmIdBuilder example

The documented example keyed the stream swarm ID on resolution only
(`height ?? 0`). ABR ladders routinely carry several bitrates at the same
resolution, which share a height but have distinct identityHash — so the
second registration hit the collision guard and threw inside the player's
manifest handler, killing P2P for a config copied verbatim from the docs.

Add bitrate to the example and spell out the uniqueness precondition, with
identityHash (reproducible server-side via computeStreamIdentityHash) as the
bulletproof fallback.

Author: mrlika

api_documentation.md

@@ -661,11 +661,13 @@ For full control, configure a custom `streamSwarmIdBuilder` on the client and ap
 const config = {
   swarmId: videoUuid,
   streamSwarmIdBuilder: ({ swarmId, streamType, properties }) =>
-    `my-app-${swarmId}-${streamType}-${properties.height ?? 0}`,
+    `my-app-${swarmId}-${streamType}-${properties.height ?? 0}-${properties.bitrate ?? 0}`,
 };
 
 // Server (per quality, at transcode time)
-const infoHash = computeInfoHash(`my-app-${videoUuid}-main-${height}`);
+const infoHash = computeInfoHash(
+  `my-app-${videoUuid}-main-${height}-${bitrate}`,
+);
 ```
 
-The stream swarm ID must be deterministic and identical across all peers of a swarm, and distinct streams must produce distinct IDs. It cannot be changed at runtime. Clients can also observe each registered stream's computed identity through the `onStreamAdded` core event.
+The stream swarm ID must be deterministic and identical across all peers of a swarm, and **every distinct stream must map to a distinct ID**. Include enough properties to guarantee that: resolution alone collides on ladders with several bitrates at the same resolution, so the example above adds `bitrate`. If your ladder can have several renditions sharing those fields (e.g. different codecs at the same resolution and bitrate), add the distinguishing property too, or incorporate the stream's `identityHash` (reproduce it server-side with `computeStreamIdentityHash(properties)`). Registering two different streams with the same ID throws. The builder cannot be changed at runtime. Clients can also observe each registered stream's computed identity through the `onStreamAdded` core event.

packages/p2p-media-loader-core/src/types.ts

@@ -486,8 +486,13 @@ export type StreamConfig = {
    * on a private tracker.
    *
    * The function must be deterministic and identical across all peers of the
-   * swarm: peers whose streams resolve to the same infohash exchange segments
-   * with each other, so distinct streams must produce distinct IDs.
+   * swarm, and every distinct stream must map to a distinct ID: peers whose
+   * streams resolve to the same infohash exchange segments with each other, and
+   * registering two different streams with the same ID throws. Include enough
+   * properties to guarantee uniqueness — resolution alone collides on ladders
+   * with several bitrates at the same resolution. If in doubt, incorporate the
+   * `identityHash` from the context (reproduce it server-side with
+   * `computeStreamIdentityHash`).
    *
    * Called once per stream at registration. This property cannot be changed
    * at runtime.
@@ -503,8 +508,9 @@ export type StreamConfig = {
    *
    * @example
    * ```typescript
+   * // Include bitrate: resolution alone collides on multi-bitrate ladders.
    * streamSwarmIdBuilder: ({ swarmId, streamType, properties }) =>
-   *   `my-app-${swarmId}-${streamType}-${properties.height ?? 0}`,
+   *   `my-app-${swarmId}-${streamType}-${properties.height ?? 0}-${properties.bitrate ?? 0}`,
    * ```
    */
   streamSwarmIdBuilder?: (