perf(bench): isolate the read-scaling bottleneck (sepdb/snap)

[gburd]

Adds two contention-isolation workloads to scale_bench and records the measured ranking of the multi-core read bottlenecks.

Result

In-cache random-read sweep (12-core laptop; pattern matches the 24-core meh perf profile):

threads	rrand (shared, locked)	sepdb (own db/thread)	snap (MVCC, no page locks)
4	~480k	~638k	631k
8	~340k	~502k	459k
12	~340k	~417k	389k

• sepdb (no shared page) is 30–50% faster → shared hot-page contention is real.
• snap (no page locks, reused locker) scales to 4t but still plateaus at 8–12t → the cap is the buffer-header page pin in __memp_fget, not the lock manager.

Conclusion (drives the prototype order)

1. 5.3.28 tag problem (same than 5.3.21) #2 buffer-header page pin — dominant cap; even lock-free reads ceiling at the same point.
2. Berkeley DB JE (Java Edition) is missing #4 lock manager — secondary 2–8t cost (page read locks + per-op locker alloc).
3. 6.0.19 is missing #3 write path — fsync-bound, independent (group commit).

Also replaces pthread_barrier (absent on macOS) with a portable start gate so the harness builds on Linux/FreeBSD/macOS. Full analysis in docs/design/scaling-findings.md.