Fix initial period prediction in multithread mode

While checking why some test on #1927 didn't pass I realized that this
was due to an actual real performance issue in multithread mode in rare
scenarios.

Basically, the `WorkerMain` module - whose role is to setup everything
worker-side in multithreaded mode - gives a hint of what could be
expected to be the first Period to load in the content.

However, it always gave the first Period - I guess we put a placeholder
when first writing the code and forgot to replace it until now.

As this is only a hint, this doesn't really led to any important issue,
the only visible problem - and why some integration tests failed
sometimes - were that the actual module relying on that information took
some time (the next playback observation so from 0 to 1 second) before
correcting the value.

In very specific scenarios, this could mean loading 1 second later than
usual (this wasn't really visible on initial load here but it happened
in tests for RELOADING cases).

src/core/main/worker/worker_main.ts

@@ -594,7 +594,7 @@ function loadOrReloadPreparedContent(
   );
 
   StreamOrchestrator(
-    { initialPeriod: manifest.periods[0], manifest },
+    { initialPeriod, manifest },
     playbackObserver,
     representationEstimator,
     segmentSinksStore,