add latency and configurable param context

Author: roethke

docs/base-chain/flashblocks/faq.mdx

@@ -128,9 +128,9 @@ For a comprehensive introduction to how Flashblocks work, see the [Flashblocks O
   <Accordion title="Why does eth_call 'pending' report a block number several blocks behind tip?">
     This is expected behavior. Flashblocks-aware nodes store up to 5 historical blocks worth of Flashblocks state to prevent race conditions. When `eth_call "pending"` is called, it operates on top of that historical base, so the block number visible in the call context (e.g. `block.number`) may appear to be N-5.
 
-    Importantly, **the result of the call is correct** — it reflects the latest sealed block plus all received Flashblocks at the time of the call. The reported block number is an artifact of how the pending state is constructed internally, not a sign that the call used stale data.
+    When `eth_call "pending"` executes, the entire block context — `block.number`, `block.timestamp`, `block.basefee`, and all other block properties — corresponds to that historical base block (potentially N-5), not the current chain tip. **The call result is correct** in that it reflects all received Flashblocks state applied on top, but contracts that rely on block context properties should be aware that those values may be several blocks behind.
 
-    If you need the call context to explicitly reflect the most recent preconfirmed block number, use [`eth_simulateV1`](/base-chain/flashblocks/api-reference#eth_simulatev1) instead, which supports full state overrides and executes against the live Flashblock state.
+    If you operate a node in a geographic region where your P2P latency is not significantly higher than the WebSocket stream latency, you can reduce this difference by lowering the `MAX_PENDING_BLOCKS_DEPTH` configuration value. This controls the maximum number of historical blocks worth of Flashblocks your node stores, so a lower value will make the block context closer to tip at the cost of reduced tolerance for P2P latency spikes.
   </Accordion>
 
   <Accordion title="What RPC methods support Flashblocks?">