Track sequential latency on id-derived negative residency reads #1114

#1112 deliberately requires every listed non-self holder to answer before an unversioned empty can establish absence. Its existing sequential GET_RECORD loop therefore adds latency to id-derived missing-key reads. This is an accepted correctness tradeoff in the current draft, not a reason to weaken the all-holders rule or terminal versioned-answer behavior.

An isolated comparison used the actual main/branch loader bodies with loopback WebSockets, five warmups and twenty measured samples. Empty replies delayed by 10 ms produced branch medians of 10.7/21.2/31.4 ms for one/two/three holders, versus main’s approximately 10.6 ms. A 10 ms first holder and 100 ms second holder produced111.0 ms versus10.5 ms. A first-holder versioned deletion remained one request at approximately10.5 ms. This measures the mechanism, not production latency.

Before optimizing, measure realistic missing-key workloads and decide whether the added delay warrants retrieval concurrency. Parallel GET_RECORD currently initiates parallel relocation, so any optimization must coordinate competing answers and relocation. Preserve the approved rules: the first versioned live/deletion answer settles; all weak-empty holders must answer; an unreachable holder prevents weak absence and yields502. No quorum/read-repair read is requested.

Review-Deferral: 731730d933ac1561 severity=minor category=performance

_{🤖 Generated by OpenAI Codex; posted via @kriszyp.}