Crate macrame-db 0.12.0, wheel 0.12.0, schema v10 unchanged. No schema rung and
no API change; a 0.11.0 database opens with nothing to do.

There IS a behaviour change and it is the release: the four bulk paths no
longer split their batches at a fixed size. The actor times its own transaction
and the caller-side loop sizes the next chunk from it, so chunk_rows becomes a
ceiling rather than the size. D-143 established that no row count can bound a
duration on a path whose per-row cost grows with the table; this is that
finding acted on.

Measured on the D-088 matrix: the typical stall halved (3.4-3.7 ms against
7.1-8.3), the worst stall did not move (7.7-10.2 against 7.6-15.2), and
throughput cost 9-20%. The worst chunk is the first one, at the ceiling, before
feedback exists -- a structural limit of feedback rather than a controller
failure, and the successor named for 0.13.0.

The cost, stated rather than absorbed: chunk boundaries are now machine- and
load-dependent, so the same batch can land under a different number of
recorded_at stamps run to run. Everything else §5.1.6 promises is intact -- one
transaction per chunk, one stamp per chunk, a prefix and never half a chunk.
write_bulk_atomic is the escape hatch and always was.

Two measurements came out worse than the plan assumed and both are published.
The floor's cost was an extrapolation from a sweep and is 3.11-3.43 ms rather
than the 4.1 ms it shipped documented at. And R15's rate, measured properly for
the first time on the step everyone had been quoting, turned out not to be a
rate at all: 45 / 60 / 75 / 78 / 93% are five machines under five loads, not
five estimates of one number.

The study that established that found a flaky test first, and it was one this
release had just written: the test rewritten to stop pinning chunk boundaries
had pinned one, three lines under a comment naming the hazard.

Suite: 348 Rust, 357 with metrics across 29 targets, 355 Python passed and 2
skipped.

D-146, D-147. Full note in docs/releases/v0.12.0.md.