An Event trigger's firing rate is invisible until it starts billing

### Before filing

- [x] I searched open and closed issues for this proposal.
- [x] I checked the docs and the current behaviour on `staging`.
- [x] This is one change, not several.

## Reason: what you cannot do today

There is no way to see how often an Event trigger will fire before enabling it.

Every dispatch is a billed workflow execution. An Event trigger is a contract address plus an event name, and nothing in the builder or the API relates that pair to a rate. `Transfer` on a major ERC-20 and `OwnershipTransferred` on the same contract are the same amount of configuration and differ by four or five orders of magnitude in how often they fire.

The failure is not that a busy trigger is wrong. Some of them are exactly what the user wants. It is that the rate is invisible at the moment the decision is made and arrives later as a bill.

Split out of #2491 at triage's request. That issue covers whether an Event trigger can register at all, which is a different question with a different owner: will it run, versus what will it cost. They share only a resolved target.

## Reason: what the workaround costs

Enable the workflow, watch the Runs panel, disable it if the rate is alarming. That is a live experiment paid for in executions, and the feedback loop is as long as the event is rare.

Outside the product you can point a block explorer or your own `eth_getLogs` at the contract and count, which works but requires you to already know the topic hash and to have somewhere to run it.

I have not measured the cost and I am not claiming a figure.

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

Counting matches for a configured Event trigger over a bounded window of recent blocks, and reporting a rate derived from it.

Out of scope, and this is the part that matters given where the first attempt went wrong: any conclusion drawn from an empty result. `lib/rpc/rpc-config.ts:83-87` records that some providers rate-limit by returning empty result sets rather than erroring, so an absence of logs is not evidence of an absence of events on this infrastructure. A count is a positive fact and can be reported. "This never fires" cannot, and belongs to #2491's `eth_getCode` check instead.

Also out of scope: Solana event triggers, `stateThreshold` triggers, and whether the result is surfaced in the editor.

## Plan: what you propose

I do not have a plan I would defend yet, and I would rather say that than propose the shape that was just rejected.

What I know has to be settled first:

- **Where it lives.** It is not `validate_workflow`. That surface is a fast tier with no network calls, and a log scan is neither. A separate endpoint is what #2491 tried and triage declined for the registration half; whether the volume half earns one on its own is the open question.
- **What bounds it.** The first attempt chunked `eth_getLogs` at 2000 blocks and checked its ceiling after each chunk had already been materialised, which on a busy contract is the failure mode rather than the guard. Any version of this needs the bound pushed into the provider call, and needs a cost model that survives a contract emitting far more than the ceiling.
- **Whether a sampled window is honest enough.** A rate from a recent window is an extrapolation. It is wrong across a deploy, an airdrop, or any burst, and I do not know whether a number that can be wrong in that direction is better or worse than no number.

What I would need to determine to choose: whether the existing RPC budget can absorb a bounded count at all, and whether there is a cheaper source for it than counting logs.

## Plan: alternatives you considered

1. **Do nothing.** The rate stays invisible until the bill. Defensible if the RPC cost of answering is worse than the surprise.
2. **Bill-side rather than chain-side.** Alert on execution rate after the fact from data KeeperHub already holds, instead of predicting from chain history. Cheaper, needs no RPC, and catches the real runaway. It answers later than the user wants but it answers from facts rather than extrapolation, and it may simply be the better feature.
3. **Count without extrapolating.** Report matches in a window and no rate. Weaker, but nothing in it can be wrong.

Option 2 is the one I would most want an opinion on before anyone writes code.

## Scope: compatibility

- [ ] Changes an existing response shape, status code, CLI flag, or default.
- [ ] Adds, removes, or upgrades a dependency.
- [ ] Changes database schema or requires a migration.
- [ ] Touches authentication, permissions, validation, or spend limits.
- [ ] Changes pricing, plan limits, or anything a user is charged.

Nothing is ticked because there is no plan yet. Any of the first, fourth and fifth could become true depending on which shape is chosen.

Start by reading lib/rpc/rpc-config.ts:83-87 and the validate_workflow surface named in the issue, then resolve whether chain-side bounded counting or bill-side monitoring is the intended direction. Done requires an agreed scope and behavior for positive event counts or rates, including provider limits and empty results; the issue currently names no implementation file or test.

Written by the indexing model from the issue text.