Gas-limit estimation: receipt-informed estimates instead of fixed per-method ceilings

[Reiers]

vm/gasestimate.go EstimateGasLimit uses fixed ceilings: 1M (transfer), 1B (EVM InvokeContract), 75M (other builtin) + 25% margin. Live calibration send today (PR #144 evidence): estimated 1,447,776 vs 738,263 used — ~2x overpay on the cheapest possible message.

Problems:

• Overestimation burn: Filecoin burns a portion of (gasLimit − 1.1×gasUsed) at inclusion. Every message overpays, worst during base-fee spikes.
• Inclusion risk: a 1B-gas-limit message occupies 10% of a block's gas budget. Miners pack blocks by reward density; oversized limits deprioritize our messages vs identical traffic sent through lotus (execution-based estimates).
• Lotus applies the message on top of pending state (GasEstimateGasLimit → CallWithGas) — we can't do that bridge-off without the FVM (Stage C: pure-Go FVM via wazero (remove filecoin-ffi dep #2) #89 Stage C).

Proposal — receipt-informed estimation (light-node-native):

1. Scan recent local retention (we already store receipts) for messages with the same To + Method; use max(gasUsed) × 1.5 capped by the current ceiling. PDP proofs, WindowPoSt, rail settlements are highly repetitive — after one observed instance, estimates get tight.
2. When a VM bridge IS configured, forward gas estimation to it (exact), keeping local as fallback.
3. Keep today's ceilings as the cold-start fallback.

Follow-up from the eth_gasPrice fix in v1.9.1 (#143).