perf: skip H2 for full-tunnel batch requests

[yyoyoian-pixel]

Summary

Full-tunnel batches already coalesce N ops into one HTTP request — H2 stream multiplexing has nothing to multiplex. This PR skips the H2 path for tunnel_batch_request_to and keeps the H1 pool at full capacity.

H2 multiplexing remains active for relay mode (non-full) where each browser request is a separate HTTP call that genuinely benefits from stream multiplexing.

Problem

H2 for tunnel batches introduced three regressions vs v1.9.14:

1. Long-poll stalls: idle polls complete at 16–17s (LONGPOLL_DEADLINE + network latency) instead of timing out at 10s on H1. Each poll holds an Apps Script execution slot 60% longer.
2. Silent batch drops: RequestSent::Maybe failures drop the entire batch with no retry — a failure mode H1 doesn't have.
3. Pool starvation: POOL_MIN_H2_FALLBACK trims the H1 pool from 8→2 once H2 connects, but tunnel batches still use H1 and need the full pool.

A/B test results (Pixel 6 Pro, 30 batch samples each)

Metric	H2 (stock v1.9.20)	H1 (this PR)	v1.9.14 (baseline)
16–17s batches	8–10/30	0/30	0/30
10s timeouts	0	4/30	5/30
Active RTTs	1.4–2.4s	1.3–2.2s	1.4–2.3s

This PR restores v1.9.14 tunnel performance while keeping all v1.9.15+ improvements (H2 for relay, zero-copy mux, block DoH/QUIC, TLS pool tuning).

Changes

• tunnel_batch_request_to: remove H2 try/fallback/NonRetryable block, go straight to H1 pool acquire() (-54 lines)
• run_pool_refill: always maintain POOL_MIN (8). Remove POOL_MIN_H2_FALLBACK (2) trim that starved tunnel batches (-12 lines)

Test plan

• cargo check clean
• A/B tested on Pixel 6 Pro — v1.9.14 performance restored
• Four separate sample runs confirm zero 16-17s stalls with H1
• H2 still active for relay mode (not affected)

🤖 Generated with Claude Code

[therealaleph]

Reviewed via Anthropic Claude. Verified locally:

• cargo test --lib --release: 209/209 ✅
• cargo build --release --features ui --bin mhrv-rs-ui: clean ✅

The architectural reasoning is sound: tunnel batches are already-coalesced single HTTP requests where H2 stream multiplexing has no value (nothing to multiplex). H2 multiplexing genuinely shines on relay mode (one HTTP call per browser request, dozens parallel) — and you've explicitly kept H2 there. The A/B data on Pixel 6 Pro is concrete (8-10/30 stalls → 0/30).

Two things I want to verify before merging:

1. Interaction with PR #1029 (just merged in v1.9.20): that PR was @rezaisrad's fix for the 3-week #924 cluster — same warm() race in domain_fronter.rs that this PR also touches. Their fix parallelized h1 prewarm with h2 handshake and added H2Cell.dead AtomicBool for synchronous dead-cell detection. With this PR removing the h2 path for tunnel_batch_request_to entirely, the H2Cell.dead flag stops getting consulted on the tunnel batch path — that's fine (no regression) but the dead-cell logic now only covers relay mode. Worth a one-liner comment in the changelog noting this.

2. Cross-check vs #962 (r0ar's data): that issue's controlled A/B showed h2 enabled was strictly better than force_http1: true for apps_script mode, not Full mode. Your PR scopes the skip to tunnel_batch_request_to only (Full mode batch path), so r0ar's apps_script users keep h2 — same trade-off as your "H2 still active for relay mode" claim. Just confirming this matches the diff.

Plan: leaving open for 3-5 days community testing. Specifically asking testers:

1. Cold-start Full mode after mhrv-rs restart — does v1.9.20+this PR feel snappier than stock v1.9.20?
2. Long sustained browse session (>30 min) — any new stalls or disconnect patterns?
3. Mixed apps_script + Full mode (run both deployments via separate script_ids): does relay mode latency regress?

If 2-3 testers confirm "feels like v1.9.14 again" without surprise regressions, I'll squash-merge as v1.9.21.

Excellent perf work — the empirical bisect-into-h2-overhead is the right framing for these kinds of low-level transport regressions.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}