fix: add gas estimation bounds to prevent out-of-gas reverts

[MoonBoi9001]

Summary

Stale RPC providers can return low gas estimates when simulating transactions against outdated blockchain state. This caused out-of-gas reverts during oracle startup, as seen in transactions:

• 0x1cf2be67736df8f55a5af2d3fa6f6b94cca3e68655a406954a35f5e4be29cdf1 (nonce 450, reverted)
• 0xe64a0a0371730551ffe8a4e80cfc197c0e9ab2d45b66d905756d6f6dc85b6b8f (nonce 452, reverted)

Both failed transactions had gas limit of 268,150 while the successful transaction used 630,655.

Changes

• Increase gas buffer from 25% to 100% (2x multiplier)
• Add 750k gas floor as safety net for low estimates
• Cap gas at estimate + 750k to keep limits reasonable
• Update tests to cover floor, buffer, and ceiling cases

Gas Estimation Logic

gas_with_buffer = estimated_gas * 2.0
ceiling = estimated_gas + 750_000
gas_limit = max(750_000, min(gas_with_buffer, ceiling))

Estimate	2x Buffer	Floor	Ceiling	Result
100k	200k	750k	850k	750k (floor)
500k	1M	750k	1.25M	1M (buffer)
1M	2M	750k	1.75M	1.75M (ceiling)

🤖 Generated with Claude Code

[RembrandtK]

How are much do we anticipate spending on gas (in USD)?

I wonder if an alternative to react to insufficient gas error by resubmitting with increased limit (fixed factor increase each time) might both be more reliable (within in a wider limit we can keep increasing until successful without needing to be as generous in general) and more efficient (less excess gas paid)?

Not sure if practical (a complication you want for the code) or significant in terms of savings.

[MoonBoi9001]

A nominal amount, probably less than $10-20 per year in gas. But we can also prevent the number of times the oracle rotates RPC provider, reduce the number of failed transactions, and additionally make the probability of the circuit breaker going open circuit much lower.

You are correct that resubmitting with increased limit on error would be a viable way to react before rotation, and we could potentially consider that as an additional PR in the future, if we start to see rotations occuring because of gas estimation not being high enough. I dont think we will after this PR though, if it happens it would be because we have so many indexers that are elgible to submit in a batch (250 indexers currently per batch) that the gas cost is still higher than our (generous) bounds allowed here.

There should not really be any additional costs by increasing the gas limit from whatever was previously estimated e.g. 630k, to a new floor value of 750k, as each transaction will only consume as much gas as it needs, the rest being unspent. But there is a non zero cost of a failed transaction as it has to be resubmitted.