docs(perf): rewrite the bare-metal report for its audience; correct a stale roadmap status

[lspecian]

Documentation only. No code, no behaviour change.

The bare-metal performance report was written as a worklog

It opened with a post-mortem of a previous revision, carried internal identifiers
(RP-9, RP-10, OQ1, PR #29) throughout, had sections titled "Still owed"
and "Open Question 1, answered", and named the specific machines it ran on. A
reader arriving at the repository had to work through the document's own history
before reaching a number.

567 lines → 289. Nothing measured was dropped — every figure, sample set and
NIC reading is preserved, verified by spot-check.

What changed:

• Leads with the numbers, and with the round-trip vs batched distinction that
  makes them comparable, instead of with what a previous revision got wrong.
• The withdrawn figures are one short note at the end. They deserve
  acknowledgement — someone may arrive remembering 837,284 msg/s — but three
  sentences serve that reader better than four sections, and the narrative said
  nothing about current performance.
• Internal identifiers removed. "Open Question 1, answered" became "What
  limits each number", which is what a reader actually wants from that section.
  "Still owed" became "Known limits of this report".
• Machine names removed; the hardware specification is kept, because that is
  the useful part. A public report should not map someone's LAN.
• The bug-fix appendix is gone — that belongs in the changelog.
• Measurement traps kept and promoted to their own section, since anyone
  benchmarking this system will hit them: sub-ten-second runs measuring the
  client's send buffer rather than the broker, --linger-ms destroying a
  synchronous benchmark, and throughput alone being unable to distinguish a fast
  broker from a failing one.

The same three internal identifiers are stripped from BASELINE_PERFORMANCE.md,
whose structure was already reader-first.

RP-3.1's status was stale

It read CODE COMPLETE — unit-tested, not yet exercised on a cluster while all
three of its boxes were ticked. Leader epochs were exercised on a cluster, and
RP-3.3 is the evidence: staging real divergence surfaced a bug where replicated
assignments were rebuilt without their epoch, so every follower's copy read epoch
0 forever and truncation could never fire. No unit test reaches that — it needs
two nodes disagreeing about an epoch.

Leaving it as written implied the epoch work was less proven than it is, in the
phase where "proven" carries the most weight.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review available on request

• 🔍 Trigger review

Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment @coderabbitai review to review the latest changes. For a full review, comment @coderabbitai full review.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7d0779a9-1166-49ea-aedc-33205ddf0e98

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}