fix: seed position_ledger from create tx in dhook Create handler

[RhizoNymph]

Summary

The newer DopplerHookInitializer (0xBDF938...) doesn't re-emit ModifyLiquidity at the initializer level for seeding, and the seeding PoolManager.ModifyLiquidity logs fire at a lower log_index than the matching Create event in the same tx — so by the time the PoolManager:ModifyLiquidity handler runs, the pool isn't in the dhook cache yet and the upsert short-circuits. Net result: affected pools have an empty position_ledger, and every downstream Swap computes reserves = computeReservesFromPositions([], tick) = {0, 0}.

This patch closes the leak going forward by replaying the create tx's receipt in the DopplerHookInitializer:Create handler:

• Add seedPositionLedgerFromCreateTx({ poolAddress, context, txHash }) that pulls getTransactionReceipt, filters PoolManager + ModifyLiquidity topic + topic1 == poolId, decodes (int24, int24, int256, bytes32), and feeds each delta to the existing upsertPositionLedger.
• In the Create handler, call it right after insertPoolIfNotExistsDHook + cache registration, then compute reserves from the now-populated ledger via getPositionsForPool instead of fetchPositions.

One RPC call per Create event; no block-range walking; naturally scoped to the create tx so future ModifyLiquidity events still go through the standard PoolManager handler (which now succeeds because the cache has the pool).

Follow-up

Pools created before this lands still have empty ledgers and need scripts/backfill-position-ledger.mjs --schema prod ... --apply to repair. Verified by hand against 0xf12523285529af9b21d9e9687c02c58cf5559ba3 on Base — its create tx (0x9758db0b..., block 46821559) contains exactly the two seeding PoolManager.ModifyLiquidity logs this handler would now decode and persist ([119600, 229600] → 1.028e24 and [-887200, 119600] → 2.530e24).