Fix: Standardize Stream Ordering to Prevent Swarm Pollution

[DimaDemchenko]

Description
This PR fixes a critical issue where P2P peers were unable to share segments due to mismatched stream IDs caused by randomized manifest ordering from the CDN.

The Problem
Our current demo manifest URL returns live stream qualities in a randomized order. This appears to be a load-balancing optimization on the AWS/CDN side (likely to distribute the "default" quality selection across users).

Our P2P core relies on the index of the stream to identify and share segments.

Example Scenario:

• User A receives: [720p, 480p, 360p, 160p] -> Internal Stream IDs: 0, 1, 2, 3
• User B receives: [360p, 160p, 720p, 480p] -> Internal Stream IDs: 0, 1, 2, 3

If User A tries to share a segment from Stream ID 0 (720p), User B rejects it because their Stream ID 0 expects 360p content. This effectively fragments the P2P swarm, isolating users who received different manifest orders.

The Fix
We now enforce a consistent, standardized order for all streams on the client side, regardless of the random order sent by the server.

Before registering streams with the P2P engine, we sort them using a strict rule:

1. Primary Sort: By Bitrate.
2. Tie-Breaker: By URL or ID.

This guarantees that "Stream 0" always maps to the exact same video quality for every user in the swarm, ensuring they can successfully share segments even if their manifest files looked different initially.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.