docs: distinguish RPC gascap from protocol and block gas limits

[kutluhaneth46]

Summary

Clarify in BREAKING_CHANGES.md v0.7.2 that --rpc.gascap is a node-local simulation limit, distinct from the EIP-7825 per-transaction protocol cap and the block gas limit — addressing the false "transaction is impossible" conclusion when eth_estimateGas fails.

Adds a For Application Developers section with:

• Three-limit framing (RPC cap / protocol cap / block budget)
• Observable error shapes for cap vs balance vs revert
• EIP-7825 post-Osaka note (effective ceiling min(--rpc.gascap, 2²⁴))

Fixes #271. Complements #297 and public-testnet-rpc.md ( #299 ).

Test plan

• Docs-only change
• Cross-link to public-testnet-rpc.md resolves within repo

[osr21]

Disclosure: this PR implements the docs fix I outlined on #271, so I re-verified rather than just re-reading my own suggestion back.

Content verification

• Three-limit framing — matches the repo: --rpc.gascap defaults to 30M node-locally (crates/node/src/args.rs, confirmed live via a 401(from)/estimate that clamped silently rather than erroring), the EIP-7825 protocol cap is 16,777,216 and enforced in the EVM layer regardless of provider (crates/evm/src/evm.rs tests explicitly disable it to exceed 2²⁴ in fixtures), and the 30M block gasLimit is confirmed live via eth_getBlockByNumber. ✔️
• min(--rpc.gascap, 2²⁴) framing — correct and consistent with the docs: add public testnet RPC guide for gas caps and rate limits #299 doc's identical claim, which I merge-tested and verified independently there.
• "Do not treat an estimate failure above 2²⁴ as proof a higher limit would work on-chain" — correct; this is the load-bearing sentence and it's stated exactly right.

One correction worth making before merge

The line "no distinct JSON-RPC code" overstates the ambiguity. I ran fresh probes today:

• A genuine EVM revert (ERC20: transfer amount exceeds balance, and separately ERC20: transfer from the zero address) both returned JSON-RPC code 3 — the standard EIP-1474 execution reverted code, distinct from the cap/balance family.
• Cap- and balance-derived rejections return -32000/-32003 (per the arc-node #292/docs: add public testnet RPC guide for gas caps and rate limits #299 investigation), never 3.

So at the raw JSON-RPC level, revert is distinguishable from cap/balance by code alone — the ambiguity this section is warning about is real, but it's specifically between the RPC-cap, protocol-cap, and balance-derived shapes, which do all share the -32000/-32003 allowance (<N>) / exceeds: <N> message family with only the numeric value disambiguating them. The one place revert genuinely gets flattened into that same bucket is client-side: viem wraps a -32000 allowance error as ExecutionRevertedError, which is exactly the trap this PR is trying to prevent — worth naming that as the actual failure mode (library-level, not raw-RPC) so a developer reading raw JSON-RPC responses doesn't think revert-vs-cap is unrecoverable by code, only cap-vs-cap-vs-balance is.

Suggested rewording: "no distinct JSON-RPC code separates the two gas-budget shapes from each other (compare the numeric value); a genuine revert is a different raw code (3), though some client libraries re-label a cap/balance error as a revert error — check the raw response, not the library's error class name."

Process notes

• Test-plan claim doesn't match the diff. The checklist says "Cross-link to public-testnet-rpc.md resolves within repo," but the diff adds no link to that file — worth adding one (e.g. "see Public Testnet RPC Guide for the endpoint table and fallback pattern") since the PR body explicitly frames this as complementary to docs: add public testnet RPC guide for gas caps and rate limits #299/docs: classify JSON-RPC breaking changes for application developers #297.
• No conflict with docs: classify JSON-RPC breaking changes for application developers #297 despite both touching BREAKING_CHANGES.md — merge-tested clean in both orders; they land in non-overlapping regions of the file.