Load test the booking path: how many simultaneous bookers does yoyaku bear?

Adds the load harness this issue asks for, and the baseline it produced.

What is here

• tests/load/drive.php, a driver that walks the real journey with many visitors at once, each with a cookie jar of its own, mixed between browsing, booking and abandoning. One curl_multi loop rather than a process per visitor.
• tests/load/sample.php, which names what is saturating: web server workers, database threads and row lock waits read out of performance_schema.data_lock_waits, memcache hits and evictions.
• tests/load/aggregate.php, throughput and percentiles per step.
• yoyaku_load_test, a hidden test module: yoyaku:load-seed, yoyaku:load-clear, yoyaku:load-check.
• LoadFixtureCheckTest, which pins the check itself. A check that cannot fail asserts nothing, and this one only ever runs against a rig where a real double booking cannot be arranged on purpose. Verified by mutation: counting places the way PlaceAvailability does, as a set, makes the test fail.
• docs/load-testing.md, and a new register in docs/performance.md.

What it measured

The knee is between 40 and 80 simultaneous bookers on this rig, and what it queues on is the slot row lock: at 80, 48 transactions waiting at once and 13871 of 13877 wait edges on yoyaku_slot row 1.

Spreading the same 80 visitors over four sessions is worth 65 per cent more holds a second, which is the price of the no-overbooking guarantee, quantified.

The guarantee itself holds under a rush that cannot be satisfied: 60 bookers on a hall of 200 places ended with exactly 200 holds, 4281 refusals, no failures and no place held twice, with the driver's count and the hall's own count agreeing.

Absolute figures are one machine's and do not transfer; the doc says so with every table.