No way to trigger on an upstream signal (oracle report, bridge queue, timelock) before it lands on chain

Part of #2239. Tier 3 of four.

## Reason: what cannot be done today

Where reacting *before* something lands on chain is valuable, the causing signal is usually observable off-chain before the transaction exists - and KeeperHub cannot subscribe to any of it.

Liquidation defence is the clearest case. The useful signal is the **oracle price update** that will make a position liquidatable, not the liquidator's transaction. Chainlink OCR reports and Pyth's Hermes stream are visible over ordinary subscriptions before the corresponding on-chain write. By contrast, by the time a liquidator's transaction is visible in a mempool the user is racing a searcher with a colocated node and a direct builder connection, and will lose.

The same shape holds for:

- **Bridge messages** queued on a source chain before relay
- **Governance actions** sitting in a timelock with a known execution window
- **Scheduled protocol actions** with published parameters

In each case the "before" signal is a cheap subscription to the system that will cause the on-chain event.

**What the workaround costs:** the user runs the subscription themselves and drives KeeperHub through the Webhook trigger, which means operating their own always-on service - the thing they came to KeeperHub to avoid.

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

**In scope:** a trigger source that subscribes to off-chain feeds and fires on the upstream signal.

**Not in scope:** tiers 1, 2 and 4. Also not in scope: acting on the signal with any ordering guarantee relative to other transactions.

**Which feeds first is deliberately open.** Candidates are Chainlink OCR reports and Pyth Hermes, but the choice should follow which protocols users actually monitor rather than which integrations are easiest.

## Plan

1. Establish which feeds matter, from real workflow usage rather than from what is technically available. This is the part maintainers should answer.
2. Design the subscription and matching model for one feed end to end before generalising. A premature abstraction over "feeds" is a likely failure mode here - two feeds is not enough evidence to design an interface.
3. Settle the semantics question below.

**These triggers are speculative in a way tiers 1 and 2 are not.** The upstream signal may not produce the expected on-chain state - a price report can be superseded, a queued bridge message can fail, a timelocked action can be cancelled. A trigger that fires on the upstream signal is therefore firing on a prediction. That needs to be explicit in the product rather than presented as equivalent to an event trigger, and it has billing implications: an execution consumed on a prediction that did not come true is still an execution the user paid for.

**Reliability becomes ours.** Once a feed is a trigger source, its availability and authentication are part of KeeperHub's uptime surface in a way that upstream RPC currently is not. Failure semantics - what a workflow does when a feed drops - should be part of the design, not an afterthought.

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

No files, tests, or entry points are named. Start by establishing which upstream feed users actually need, then design and validate one feed's subscription and matching flow end to end. Done means the chosen upstream signal can trigger a workflow with explicit prediction, failure, availability, and billing semantics.

Written by the indexing model from the issue text.