Pre-inclusion triggers on Arbitrum via the sequencer feed

Part of #2239. Tier 4 of four, covering `arbitrum-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, different mechanism again.

**Arbitrum has no meaningful public mempool** - ordering is decided by the sequencer. But unlike Base, Arbitrum publishes a **sequencer feed** carrying the finalised ordering of transactions before they are posted to L1. That makes it the strongest pre-inclusion observation point of any chain we support: it shows not merely that a transaction exists, but where it will land.

That difference matters for what can honestly be offered. On a public mempool the answer to "will this transaction land, and in what position" is "probably, somewhere". On the Arbitrum feed it is much closer to known.

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

**In scope:** subscribing to the Arbitrum sequencer feed and exposing sequenced-but-not-yet-posted transactions as a trigger source on `arbitrum-mainnet`.

**Not in scope:** the other tier 4 chains; submission-side ordering.

**Explicitly unverified:** the endpoint (`wss://arb1.arbitrum.io/feed` is the commonly cited one) and the message schema both need checking against current Arbitrum documentation. Availability guarantees of the public endpoint are unknown and are a real dependency, not a detail.

## Plan

1. Verify the feed endpoint, message format, and the decoding work between a raw feed message and a trigger match.
2. Decide whether to consume the public endpoint or run a feed relay. This is a reliability question - taking a hard dependency on a public endpoint for a trigger users pay for needs an explicit decision.
3. Determine what ordering guarantee the feed actually provides, and therefore what can be promised. This is the most interesting question on this issue: if the guarantee is strong enough, an Arbitrum trigger could offer something meaningfully better than "probably will land", and that should shape how it is presented rather than being flattened into a generic pre-inclusion trigger.

Same speculative-execution and billing considerations as the other tier 4 issues, though weaker here in proportion to how strong the ordering guarantee turns out to be.

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

No files, tests, or implementation entry points are identified. Start by verifying the current Arbitrum sequencer-feed documentation, including the endpoint, message schema, decoding path, and ordering guarantees. Done means an explicit design decision on feed consumption, reliability, trigger semantics, and what ordering guarantee can be promised before implementation begins.

Written by the indexing model from the issue text.