Pre-inclusion triggers on Base need Flashblocks, not a mempool

Part of #2239. Tier 4 of four, covering `base-mainnet`.

> **Sequencing.** This is tier 4. Tiers 1 to 3 come first, and the lead time this buys is not usable until the reaction path is shortened - that work is tracked internally and is not yet done. This issue is filed for visibility and design discussion. Please comment before starting implementation work.

## Reason: what cannot be done today

Same underlying gap as the other tier 4 issues - no pre-inclusion visibility - but Base needs a different mechanism, which is why it is filed separately.

**Base has no public mempool of consequence.** Ordering is decided by the sequencer's private txpool, so watching public pending transactions shows submissions without showing ordering, which is the part that matters. The observation point that actually corresponds to "about to be included" is Base's Flashblocks stream, which publishes sub-block preconfirmations inside the block time.

## Scope: what this touches, and what it does not

**In scope:** subscribing to the Flashblocks stream and exposing preconfirmed transactions and state as a trigger source on `base-mainnet`.

**Not in scope:** the other tier 4 chains, and the public-mempool approach - it does not apply here and building it for Base would produce a trigger that fires on submissions the sequencer may order differently or not at all.

**Explicitly unverified:** the stream endpoint, message schema, delivery guarantees, reorg and replacement semantics, and actual preconfirmation latency all need checking against current Base documentation before this is estimated. Figures circulating publicly should not be taken on trust, and this issue deliberately does not quote any.

## Plan

1. Verify the Flashblocks contract - endpoint, schema, guarantees, and what happens to a preconfirmation that does not survive.
2. Settle the product semantics question below.
3. Only then design the trigger.

**The semantics question is the hard part.** A preconfirmation is a statement about what the sequencer intends, not about what happened. Two things need answering before implementation:

- Does a preconfirmation carry enough finality for a user to act on financially, and how is that risk expressed in the product?
- What does a workflow do when it fired on a preconfirmation that was subsequently reordered or dropped? The execution has already consumed budget and may have already sent a transaction.

**A constraint worth knowing up front:** Base's block time is 2 seconds, so the entire pre-inclusion window is small, and the current end-to-end reaction path is considerably longer than that. This integration delivers nothing until that path is shortened. That is the sequencing note at the top of this issue, and it applies here more sharply than to any other tier 4 chain.

---
Tracking: [KEEP-1277](https://linear.app/keeperhubapp/issue/KEEP-1277) (internal tracker, not publicly accessible)

No files, tests, or implementation entry points are named. Start by checking current Base Flashblocks documentation for the endpoint, schema, guarantees, reorg and replacement behavior, then resolve the product semantics for dropped or reordered preconfirmations and the shortened reaction path; done means the contract and product decisions are verified and ready for design.

Written by the indexing model from the issue text.