Foundry fork mode base-fee calculation shifts from mainnet historical to internal simulator after fork block

Context

Teams adopting Foundry fork mode (v0.2.0+) for integration testing against mainnet state without production credentials rely on vm.createFork to replay historical blocks via eth_call. The fork inherits the parent chain's block.basefee at the fork block, but subsequent base-fee updates follow Foundry's internal EIP-1559 calculator instead of mirroring mainnet's actual gasUsed sequence.

Uncertainty

The simulator applies a fixed elasticity multiplier (1/8) and a deterministic update rule, which diverges from mainnet's variable congestion history. Gas reports generated on the fork can underestimate real mainnet costs, and contracts that branch on exact block.basefee values (e.g., fee-market logic, EIP-1559-aware routers) may behave differently in the fork than on live mainnet. Impersonation via vm.prank further limits scenarios requiring valid ecrecover signatures from the impersonated account.

Goal

Determine whether the fork's base-fee trajectory is sufficiently faithful for a given test suite, or whether a live testnet or shadow fork is required for fee-sensitive logic.

What is the documented version boundary where Foundry's internal base-fee calculator diverges from mainnet's historical gasUsed sequence? Which fork configuration flags (e.g., fork_retry_backoff, block-step granularity) affect the simulator's fidelity? How can a test suite programmatically detect when the fork's basefee has drifted beyond an acceptable tolerance versus mainnet historical data?