fix: identify hyperd by executable path, and report decimal MB in the bench harness

[StefanSteiner]

Two independent fixes, one commit each. They share no code and can be reviewed separately.

• 6f4e739 — fix(mcp): identify hyperd by executable, not thread name
• 77834dc — fix(bench): report decimal MB, not MiB under an MB label

---

1 — The flaky watchdog test was a real Linux bug, not timing

What was wrong. slow_health_watchdog_reaps_hyperd_after_child_timeout failed
intermittently in CI. The cause was not timing. The reaping guard
validate_hyperd_process confirmed a process's identity with
ps -p <pid> -o comm=. On Linux that reads /proc/<pid>/comm — the main
thread's name, not the process image — and hyperd renames its main thread to
hyperdMain via pthread_setname_np at startup. The guard therefore concluded
the PID was not hyperd, and stop_reported_hyperd refused to signal the very
process it exists to reap.

Why it stayed invisible for so long. Two things hid it:

• The guard is normally skipped. By the time the watchdog fires the engine is
  usually already dead, and an Err(_) if !process_is_alive(pid) arm forgives an
  identity failure on an exited process. The test was passing for the wrong
  reason — it only failed when the engine was still alive at that moment.
• macOS cannot observe the bug at all. There, ps -o comm= prints the executable
  path rather than a thread name, so every local run is green regardless.

Measured on real Linux. The old guard rejected a genuine, live hyperd
200 out of 200 times. The new /proc/<pid>/exe guard rejected it 0 out of
200 times.

The fix. Read identity from the kernel's record of the mapped executable
(/proc/<pid>/exe) on Linux, which no prctl/pthread_setname_np can rewrite,
and keep ps on macOS/BSD where it is sound.

This is engine-independent: the previous 0.0.26359 pin flakes at the same rate
as the current 0.0.26479, so it is not a regression from the pin bump.

All three slow_health_* tests shared this fragility and the single fix covers
them. A new test, hyperd_identity_guard_accepts_a_live_engine, exercises the
identity path unconditionally, so it now runs on every build instead of only when
the timing happens to expose it.

---

2 — MB/sec silently meant two different units

What was wrong. BenchRecord::mb_per_sec(), fmt_mb() and the memory_*_mb
helpers divided by 1024² while labelling the result MB — so they emitted MiB.
The sibling formatters in the same module (fmt_count, fmt_rate, fmt_size)
were already decimal, so the harness was internally inconsistent.

Why it stayed invisible. The two conventions are only 4.86% apart, and both
landed in the same column of docs/BENCHMARK_GUIDE.md: the macOS tables were
decimal MB while the Windows tables were raw MiB, under one shared MB/sec
header. Nothing in the output distinguished them.

The arithmetic that pins it down.

• macOS full scan, 3.218 s → the table reads 745.8. Decimal MB gives 745.8;
  MiB would give 711.3. So that row is decimal.
• Windows sync Inserter, 22.716 s → the table reads 100.8. That is MiB;
  decimal would give 105.7. So that row is binary.

The fix. Make the harness decimal behind a documented BYTES_PER_MB
constant, rather than relabelling the column to MiB. Relabelling would have been
the wrong direction: the macOS figures were freshly re-measured and are genuinely
decimal, so calling them MiB would overstate them by 4.86%. Installed RAM stays
binary — a 36 GiB machine must read 36.0 GB, not 38.7 — with a comment saying
why it is deliberately the exception.

The Windows tables are not converted. Their header is relabelled to an
explicit MiB/sec and footnoted instead, because that run is stale on three
other axes as well; multiplying by 1.048576 would dress stale data up as a fresh
sample.

Test placement is load-bearing here. Coverage went into a new
hyperdb-api/tests/bench_common_tests.rs target. The benches are registered as
examples with autobenches = false, so cargo test --benches runs nothing and
a #[test] inside a bench file would never execute at all.

Also fixed in passing: a narrowing i64 as i32 in gen_id, which silently
wrapped past 2^31 rows and emitted duplicate and negative IDs — corrupting the
very throughput numbers being measured. It is now
i32::try_from(..).expect(..).

---

Deliberately left for follow-ups

• The same narrowing i64 as i32 pattern remains in the per-row generators of
  benchmark.rs, async_parallel_benchmark.rs and benchmark_suite.rs. Kept
  out of a units commit on purpose.
• hyperdb-api-salesforce/examples/salesforce_auth_example.rs:425 has the
  identical MiB-labelled-as-MB defect.
• The Windows tables need re-measuring on a Windows host before both table
  headers can be unified to MB/sec (10⁶ B/s).

---

Verification

No rebase was needed. This branch's base (chore/post-rc-cleanup) landed in
main as #253, and main's only change since is the npm workflow's mirrored
hyperd pin — a file this branch does not touch. git log upstream/main..HEAD
is exactly the two commits above.

Re-run against main at 9dabbef:

Gate	Result
cargo fmt --all -- --check	clean, exit 0
cargo clippy --workspace --all-targets --all-features -- -D warnings	exit 0, 0 diagnostics (483 artifacts, 75 test targets)
make test	1597 passed, 0 failed, 50 ignored, exit 0
npx markdownlint-cli2	126 issues in 31 files — identical to baseline

Test count derivation: main is 1586, and this branch adds 11 — 10 in the new
bench_common_tests.rs plus hyperd_identity_guard_accepts_a_live_engine — for
1597. The markdownlint findings for both changed Markdown files
(docs/BENCHMARK_GUIDE.md, hyperdb-api/CHANGELOG.md) were diffed against
upstream/main's copies and are identical rule-for-rule, so this branch adds no
new findings to the existing backlog.