The RPC-vs-HTTP benchmark: the number that justifies the transport, never measured

[sshaplygin]

Part of #63.

The RPC transport is built, published and unmeasured. Whether a user should reach for it over HTTP is currently answered by "it multiplexes, so presumably", which is not an answer this project accepts anywhere else.

The tooling is in place: Criterion, a main-vs-PR comparison posted to every pull request, and the discipline docs/format-comparison.md established — pre-registered predictions, paired rounds, and a harness that refuses to report when the rounds cannot separate the signal.

• point lookups at rising concurrency — 1, 8, 64, more — since multiplexing is the entire claim and it cannot show at one in flight
• p50 and p99, not means: the tail is where a shared connection either helps or hurts
• drive both legs through ytsaurus-api, so what is compared is the transport and not two different APIs
• pre-register the prediction before the first round
• publish it either way, including "no difference below N in flight" — that is a useful result and the likelier one at small scale
• turn the number into user-facing guidance: which transport for which workload, in the READMEs