Discrep in op-geth DoEstimateGas() logic leads to mempool zombies in rare cases

**Describe the bug**
When L2geth checks a transaction against the block gas limit, it fails to account for the system transaction in the block.

typical Optimism system TX gas used = 46,913 (but varies)

In other words, in DoEstimateGas, only the raw block gas limit is used (25,000,000) instead of the appropriate (25,000,000 - 46,913) = 24,953,087

If a contract call is submitted which consumes between 24,953,087 and 25,000,000 gas, it is accepted into the mempool but never settles in a block as there will never be a block with sufficient gas available for it due to the offset from the Optimism system tx in every block.

**To Reproduce**
This can be reproduced by calling a gas guzzler contract, e.g. one which accepts and stores an arbitrary array of numbers. Adjust your call's array length in order to hit the gas "sweet spot".

**Expected behavior**
What should happen is the call results in error "gas required exceeds allowance" instead of reaching the mempool.

**Notes/Suggestions**
Since it is challenging to know the exact gas expense of a systemTx ahead of time, maybe the best way to solve this is to add a buffer to the block gas limit for the limit check. (blockGasLimit - 10%) or something similar. A single execution consuming all the gas would be an oddity anyway, so this should solve it well.

Start at op-geth's DoEstimateGas logic and reproduce the issue with a gas-guzzler contract whose call uses gas near the block limit. Investigate how the Optimism system transaction affects the available gas during block construction. Done means calls that cannot fit alongside the system transaction fail with "gas required exceeds allowance" instead of entering the mempool.

Written by the indexing model from the issue text.