perf(yearn): query small parent flows on the blockTimestamp index (fix Envio 504s)

[spalen0]

Follow-up to #388, which added retries. This PR fixes the root cause of the Small parent flow monitor: Envio GraphQL request failed (HTTP Error 504: Gateway Timeout) alerts (4 of 24 hourly runs on Sep 26–27).

Why

Once a stream has a cursor, the query filtered on a blockNumber range with sinceTs=0. The Envio schema only has single-column indexes, and block numbers overlap across chains (katana's position at 43.7M falls inside Base's block range). Postgres walks the global blockNumber index through other chains' rows, and the hosted gateway gives up at about 15s. alert_large_flows filters on blockTimestamp, which is comparable across chains, and never failed.

Live benchmark against production Envio with production cursors (5 runs each):

variant	katana deposit	mainnet withdrawal	slowest overall
current (blockNumber range + _or)	median 15.1s, mostly 504	max 15.1s (504)	504
blockNumber range without _or	median 15.1s, mostly 504	max 5.6s	504
+ blockTimestamp floor	0.16s	0.16s	0.43s

The retries from #388 don't help much when a query consistently takes more than 15s, as katana deposits currently do.

What changed

• blockTimestamp >= <cursor block timestamp> now sits at the top level, next to the existing _or, so the cursor semantics stay the same.
• The cursor state now stores block_timestamp. EventCursor ordering and equality are unchanged, because the new field is excluded from comparison.
• Existing cursors without a timestamp look it up with a blockNumber equality query (about 0.15s, which is selective). They are upgraded the next time the cursor is saved. If no event is indexed at the cursor block, the monitor logs a warning and falls back to the old unfloored query.

Tests

• New tests cover the floor placement in the query, saving and loading the cursor timestamp, the floor advancing across pages, the legacy lookup and its fallback, and the lookup query shape.
• pytest: 1407 passed, 6 skipped. ruff is clean. mypy reports no new errors.
• Dry run of monitor_flow_type for all chains against production Envio, using a copy of the production state DB (no alerts sent, no state saved): every stream finished within 2.6s. Katana deposits took 0.14s.

🤖 Generated with Claude Code