fix(portal): persist discovered factory children to the sync store

[mo4islona]

The bug (critical: silent event loss after restart)

The portal historical sync discovers factory children with its wide scan and writes them only into the in-memory childAddresses map — it never calls syncStore.insertChildAddresses. Two upstream facts make that fatal:

1. Core marks requiredFactoryIntervals as cached (syncStore.insertIntervals, runtime/historical.ts) after every interval, regardless of what the sync implementation did.
2. On startup, core loads child addresses only from the store (runtime/index.ts → getChildAddresses). There is no re-derivation from stored logs.

Stock ponder holds the invariant by calling insertChildAddresses inside syncBlockRangeData (sync-historical/index.ts), in the same transaction as insertIntervals.

So a single uninterrupted run worked (the in-memory map is shared with event building and realtime), but on any restart or crash-resume of a factory app:

• factory intervals are already marked cached → discovery never re-runs (requiredFactoryIntervals is empty, so the discovery floor never covers the pre-crash range),
• the store returns zero children → the map is empty,
• → every factory-child event is silently skipped: on the resumed backfill, in historical event extraction, and in realtime.

Neither the diff harness nor the 15-chain run could catch this: both are single uninterrupted runs, and the diff compares sync-store rows, not post-restart extraction.

The fix

• Newly discovered children (not already known from the store) are queued during the wide discovery scan.
• The queue is flushed via syncStore.insertChildAddresses inside syncBlockRangeData — the same DB transaction core commits together with insertIntervals, so the invariant is atomic: factory interval marked cached ⇒ its children are in the store.
• A failed flush restores the queue and fails the interval loudly (core rolls back the transaction), so children are never silently dropped.
• Children pre-loaded from the store are never re-queued → no duplicate rows.

Tests

Three regression tests (all fail against the previous portal.ts, verified):

• persistence: discovered children are handed to insertChildAddresses in the same syncBlockRangeData call, with the factory object, creation block, and chainId — and are not re-inserted on later calls;
• loud failure: a failing insertChildAddresses rejects the interval and the same children re-flush on the retried call;
• restart: a new sync instance seeded only with what was persisted (cached factory intervals → no re-discovery) still fetches child logs — with the pre-fix (empty) store this returns nothing, which is exactly the silent post-restart loss.

Full portal suite: 56/56 passing on ponder@0.16.6 (sync-upstream.sh-equivalent tree, vite.portal.config.ts).

🤖 Generated with Claude Code