feat: add queueMessages option to waitForReady

[avigoldman]

What

Adds a queueMessages option to waitForReady(). When enabled, broadcast() calls made while waiting for the handshake are automatically queued and flushed once the other side signals readiness.

Why

Without this, consumers need to build their own message queuing logic to avoid losing messages during iframe initialization. With queueMessages: true, the consumer just calls waitForReady() and then broadcast() freely — framecast handles the rest.

API

// Parent side
const fc = new Framecast(iframe.contentWindow, { channel: 'my-channel' });
fc.waitForReady({ queueMessages: true }); // fire-and-forget

fc.broadcast(msg1); // queued
fc.broadcast(msg2); // queued
// iframe signals ready → both messages flushed automatically
fc.broadcast(msg3); // sent directly (no more queuing)

// Iframe side
const fc = new Framecast(window.parent, { channel: 'my-channel' });
fc.on('broadcast', handler);
fc.signalReady();

Testing

4 new tests covering: queue + flush on ready, flush on timeout (best-effort), no queuing after ready, opt-out with queueMessages: false.

Follows up on #44 (signalReady/waitForReady). Related: CON-6607

[changeset-bot]

🦋 Changeset detected

Latest commit: 3fd0c4d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@ciolabs/framecast	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR