test: realtime body-cap fallback catch path (createRealtimeSync) is not exercised end-to-end

[dzhelezov]

Follow-up to #144 (fix for #23).

The regression test portal/realtime-getlogs-fallback.test.ts thoroughly covers the extracted units:

• isResponseBodyTooLargeError cause-chain matching
• buildFilteredBlockLogRequests / eth_getFilteredBlockLogs dedupe/sort/over-fetch (superset) behavior
• shouldRetry non-retryability for ResponseBodyTooLargeError
• the validateLogsAndBlock empty-fallback hazard

But it does not drive createRealtimeSync / fetchBlockEventData itself, so it does not prove at runtime that:

1. the logsPromise.catch actually fires on a ResponseBodyTooLargeError from the unfiltered full-block eth_getLogs, and
2. the usedFilteredLogsFallback guard is wired so the validateLogsAndBlock skip is reached only on the empty-fallback path.

A mutation that removed the realtime catch/guard while leaving the exported helpers intact could still pass the current test file. The wiring is verified by code review and by the fork-seam gate applying the patch, but not by an executing test.

Suggested: add a focused test that stubs the rpc so the unfiltered eth_getLogs throws a ResponseBodyTooLargeError, then asserts (a) the fallback assembles the block's logs from the filtered per-filter requests, and (b) an empty filtered result skips the bloom check without crashing.