A number explained, a constant defended, and a rule that outgrew its own answer.

No schema rung, no API change, no behaviour change. A 0.10.0 database opens
under 0.11.0 with nothing to do, every public signature is what it was, and
every edit to src/ this release is documentation. What changed is what this
project knows about code it already shipped.

The 3x chunk budget miss has a cause. 0.10.0 measured a 90-row edge chunk into
an 8,000-edge table at 9.06 ms against a 3 ms bound and said the cause was
unknown. It is trg_links_current_sync: dropping the three links insert triggers
one at a time puts effectively all of the growth there -- the single-open guard
contributes none, which is D-059's v5 -> v6 index doing its job -- and within
that trigger 89% of the growth is secondary-index maintenance rather than the
upsert, which costs 0.49 ms run directly against the same table. Page-cache
pressure, foreign keys, an instrument artifact and the fixture's key
distribution were each tested and each refuted (D-142). The third nearly
published a wrong cause: the per-index arms were super-additive, and the three
fast arms were exactly the three that had run a DROP INDEX before measuring.

The four chunk_rows constants are re-derived against the D-088 matrix, which
D-059 asked for and nothing had ever applied to them. Concepts, annotations and
embeddings hold on a populated database with 1.7-2.2x headroom and cannot see
shape at all. The edge constant misses by 2.7x and all four shapes agree the
largest size inside the bound is 20, against a constant of 90 (D-143).

It stays at 90. 20 is the same defect at a different population -- per-row cost
grows with links_current, so a row count fitted at 8,000 edges is wrong at
80,000 -- while the throughput cost of turning eleven chunks into fifty is
certain and immediate. The finding is that the question was mis-shaped: D-058
had already established that the golden rule bounds duration and that a row
count is an answer to it, and this is the measurement showing that answer has
expired on one path. The fix is a time-based chunk loop, named for 0.12.0
rather than taken as a side effect of measuring.

Two gates gained something. The claim registry accepts example-backed evidence,
because attribution is not a benchmark and without it the registry could only
cover figures produced by benches/. And rustdoc is now runnable locally through
run_rust_suite.py --docs: a broken intra-doc link is a warning no test can see,
which is how 0.10.0 was tagged with one (D-144).

Suite: 340 default, 349 with metrics across 29 targets, 355 Python passed and
2 skipped. See docs/releases/v0.11.0.md.