validate: close the h3 and grpc-tls coverage gaps

[MDA2AV]

Found while working out why zix publishes nothing. Three separate holes, all in the same area.

1. The h3 profiles had no checks at all

baseline-h3 and static-h3 ran zero assertions. An entry subscribing to h3 alone finished:

=== Results: 0 passed, 0 failed ===

and exited 0 — indistinguishable on CI from a clean pass. zix-http3 has been passing that way. The docs said so out loud, and pointed at oha, which has been retired since the switch to h2load-h3.

2. QUIC had no datagram path

-p publishes tcp unless told otherwise, so an h3 entry on the bridge network got tcp/8443 and nothing on udp. No check could have reached a QUIC listener even if one had existed. Now -p $H2PORT:8443/udp is added for h3 subscribers.

3. Readiness assumed every h3 server also speaks h2

The comment claimed "H/3 servers still advertise h2 on the same TLS listener via ALPN, so this single fallback covers both cases". sark-h3 does not — it serves QUIC on udp/8443 and nothing on tcp/8443. It has failed Server did not start within 30s on every run it has ever had, while being perfectly healthy: h2load reaches it over QUIC and gets 4 2xx immediately.

Plus: unary-grpc-tls had no TLS probe

It terminates a real TLS 1.3 handshake per connection exactly like baseline-h2, but got neither the posture nor the quality probe. That is how zix-grpc passed 4/4 while serving a self-generated Ed25519 certificate on :8443 (fixed in #1303). It now gets the same two probes every other TLS profile gets.

And: a run with no assertions now fails

PASS == 0 && FAIL == 0 means unvalidated, not validated-clean. It now says so and exits 1.

curl here has no QUIC support and openssl cannot speak it either, so both the readiness fallback and the new checks shell out to the same ngtcp2-built h2load the benchmark already uses. When that image is absent the result is an explicit SKIP, counted separately from passes — a skip must never read as coverage.

Verification

entry	before	after
zix-http3	silent pass, 0 checks, exit 0	2 pass / 0 fail
sark-h3	Server did not start within 30s	2 pass / 0 fail
cardigan-grpc-tls	2 pass	7 pass / 0 fail (5 new)
zix, zix-http2, zix-ws, zix-grpc	—	unchanged, no regression

Blast radius

15 enabled entries subscribe to an h3 profile, 11 to unary-grpc-tls. The four above are the ones actually exercised here; the rest surface on the next full sweep. An entry that claims a profile it does not really serve is meant to fail this.

Also adds VALIDATE_SKIP_BUILD=1 to reuse an existing image. validate.sh does docker build --no-cache inside the timeout window, so a slow-building entry reports FAIL: Validation timed out followed by no such container: it was never created — which reads as a server failure when it is really build duration. I hit exactly that on zix: one run spent the whole 800s window inside zig build and reported a validation timeout with no such container: it was never created. Later no-cache builds of the same entry finished well inside 180s, so this is an intermittent-slow-build hazard (toolchain/dependency fetch, or this box misbehaving) rather than a fixed property of the entry — the point is only that a slow build is reported as a server failure.

🤖 Generated with Claude Code