fix(ws): skip tier:fallback escape on TipHW tip re-fetch

[shpookas]

Summary

TipHW tip re-fetch (forwardGetBlockByNumber on latest only) sets SkipFallbackEscape, so empty tip races on healthy primaries refuse-stale instead of escalating to tier:fallback (Infura / Chainstack / dRPC).

Tip routing stays on existing EvmLeaderUpstream pin (PR11) — no HTTP-twin id rewriting.

Why

After ws-tip-http-floor-test → test8, TipHW re-fetch escapes into paid fallbacks and burns Infura quota. Leader pin is the routing fix already on this branch; this PR is the cost stopgap when that miss still happens.

Test plan

• TestHttpServer_GetBlockByNumberLatest_TipRefetchSkipsFallbackEscape
• TestHttpServer_GetBlockByNumberLatest_RefetchPinsEvmLeaderUpstream
• go test ./erpc/ -run 'TestHttpServer_GetBlockByNumberLatest_'
• Canary roll

[github-actions]

	File	Lines	Key changes	Risk
🔵	eth_getBlockByNumber.go	+93/-18	—
🔵	networks.go	+28/-2	—
	2 test files	+395

_{xray — see through AI slop with deterministic architecture PR diff reviews}

[shpookas]

Added a5ebf70: the tip re-fetch now uses the leader logic on both attempts.

• First re-fetch already pinned to EvmLeaderUpstream when its poller owns TipHW (unchanged).
• When that resolve fails (TipHW adopted from Redis before the local WS delivery), the second re-fetch now re-resolves the leader instead of sweeping unpinned. By then the leader has had the first Forward's retry budget plus a forced poll (PollLatestBlockNumberNow, no debounce) to catch up, so the pin lands on the node that delivered the head. Cross-node live test on eth-mainnet reths: sibling is null 12/12 at announce time and catches up in 115-193ms, while the announcer serves its own head immediately - so pinning to the deliverer is always correct and sweeping siblings never is.
• If the first re-fetch WAS leader-pinned and still missed, the leader genuinely cannot serve; the unpinned primary sweep is kept for that case. SkipFallbackEscape stays on both paths.

New test TestHttpServer_GetBlockByNumberLatest_SecondRefetchResolvesLeaderPin: leader poller lags TipHW at first resolve, catches up after its first concrete-tip miss; asserts the stale responder receives zero concrete-tip fetches and the tip is served via the pinned second re-fetch. Note for reviewers: gock Filter counters must be gated on r.URL.Host - filters also execute while gock matches requests bound for other hosts, which silently inflates hit counters.

[shpookas]

Added 93f5b00: generalizes the guard to direct client requests - the majority of the escape volume (evm:1 over 6h: 66k getBlockByNumber escapes, at most 31k attributable to enforcement re-fetches; the rest are direct concrete-tip requests the directive-based guard never saw).

18 lines in the escape hatch: when the requested block is at or one ahead of the primary leader's poller, the miss is the sibling import race (measured 100-200ms on our reths) - primaries serve it within a block time and paid fallbacks share the same race, so escaping buys nothing. Failsafe retry re-visits primaries instead.

Deliberately NOT suppressed (HA preserved):

• blocks further ahead of the leader (primaries genuinely stuck) - existing gate-skip subtests cover this
• older-block data gaps
• block-less methods (receipts) - those still escape; separate policy question

With this, expected coverage goes from ~36% of escapes (re-fetch only) to ~77% (re-fetch + direct getBlockByNumber/eth_call at tip). Receipts (~17%) remain.

Heads up: TestFailover_GateSkipsAccumulateErrorRate is flaky on the base branch (2/3 failures, errorRate lands exactly on the 0.7 threshold depending on poller timing) - pre-existing, not from these commits.

[shpookas]

Superseded by #14 — minimal pin of near-tip eth_getBlockByNumber to EvmLeaderUpstream on first forward (PR11-shaped). Escape-hatch / SkipFallbackEscape changes dropped per review.