fix(node-sdk): deflake should stream preferences test

[insipx]

Resolves #3831

Problem

The Node SDK integration test Preferences > should stream preferences is flaky (CI failure: expected 3 to be 4). It ends its preference stream on a fixed 100 ms timer — far shorter than the 2000 ms every other streaming test in this SDK uses:

setTimeout(() => {
  void stream.end();
}, 100);

The test expects 4 updates: 2 ConsentUpdate + 2 HmacKeyUpdate. The two HmacKeyUpdate events come from registering new installations and depend on network propagation, so the 4th event frequently arrives after the 100 ms window. stream.end() then flushes the iterator early and the loop exits with only 3 updates collected.

Fix

Collect updates until all 4 expected preferences have arrived, then end the stream, rather than ending on an arbitrary fixed timer. A generous 10 s safety-net timeout (well under vitest's 120 s testTimeout) still ends the stream if fewer than 4 updates ever arrive, so a genuine regression fails with the same clear expected N to be 4 assertion instead of hanging.

const preferences: UserPreferenceUpdate[] = [];
const endTimeout = setTimeout(() => {
  void stream.end();
}, 10000);
for await (const update of stream) {
  preferences.push(...update);
  if (preferences.length >= 4) {
    break;
  }
}
clearTimeout(endTimeout);
await stream.end();
expect(preferences.length).toBe(4);

• Normal case: loop breaks as soon as all 4 arrive — the test finishes fast and no longer races a wall-clock deadline.
• Slow case: waits up to the safety-net window instead of a 100 ms deadline, eliminating the flake.
• Real regression: the safety net ends the stream and the existing assertion fails clearly.

Scope

Test-only change. No production/library code touched. All existing assertions on update ordering, types, and payloads are unchanged.

Verification

• eslint passes on the modified file.
• The remaining typecheck errors in this environment stem from the unbuilt @xmtp/node-bindings native crate (they affect every test file equally) and are unrelated to this change.

🤖 Generated with Claude Code

Note

Fix flaky should stream preferences test by awaiting 4 updates instead of a fixed timeout

Replaces the fixed 100ms setTimeout that terminated the preferences stream with a collection loop that exits once 4 updates are received. A 10s safety-net timeout ends the stream if updates never arrive, and is cleared after the loop exits. The stream is explicitly ended with an awaited stream.end() call.

^{Macroscope summarized 79c4197.}