test(metrics-pipeline,run-engine): readiness wait for the per-stream test, honest timer comment

The per-stream batches test carried the same first-emission drop race
as its siblings; it now waits for the emitter connection too. The
readiness helper's comment claimed a losing race branch rejects
unhandled, which is not how Promise.race behaves (it handles every
input); the abort's real benefit is releasing the timer promptly.

Author: matt-aitken

internal-packages/metrics-pipeline/src/consumer.test.ts

@@ -157,6 +157,7 @@ redisTest(
     });
 
     await consumer.start();
+    await emitter.waitUntilReady();
     emitter.emit(a, { op: "enqueue", q: a });
     emitter.emit(b, { op: "enqueue", q: b });
     await waitFor(() => inserted.flatMap((i) => i.rows).length >= 2);

internal-packages/run-engine/src/run-queue/metrics.test.ts

@@ -26,8 +26,8 @@ const authenticatedEnvDev = {
 
 // A dead Redis leaves waitUntilReady() pending forever (the client retries
 // indefinitely), which would burn the whole test timeout with no diagnostic.
-// Races values, not throws: a rejection in the losing branch of a settled race
-// is an unhandled rejection, so the timer is aborted and swallowed instead.
+// The abort releases the losing timer promptly so it cannot hold an event
+// loop open for the remaining 15s after a fast ready.
 async function emitterReady(emitter: MetricsStreamEmitter) {
   const abort = new AbortController();
   const timedOut = setTimeout(15_000, "timeout", { signal: abort.signal }).catch(() => "aborted");