docs(specs): order the parents family by parent manifest id

Why

parents_preview and parent_digests ordered by parent digest bytes, and index_cmr_on_ns_id_child_cm_id carries no digest, so a digest-ordered top ten per child has to sort every edge that child has: 10,603 ms with a child's edges interleaved across the heap and 2,285 ms with them clustered, at the 2,500,000-edge ceiling, against the 100 ms query budget.

The ruling orders both by the parent manifest's own id, container_manifests' UUIDv7 primary key, so the order is creation order, and a covering index over (namespace_id, child_container_manifest_id, parent_container_manifest_id) serves it with no sort. AC #135 (closed)'s set-equality clause is unchanged, children keeps the digest order under its 200-per-index cap, and the index lands with the read that needs it.

Three claims in the same section went false with the ruling and are fixed here. The section intro said the patch adds no table, column, or index. Fetch mechanism said it adds no index and owes ADR-007 nothing. And three sentences said all four page counts batch the page's manifest ids, where the referrers count batches the page's digests.

Test plan

mise run lint:docs. markdownlint and lychee report no errors, and Vale's alert set over the file is unchanged from main's, 0 errors and 264 warnings on both sides.

🤖 Generated with Claude Code

Related to #1150 (closed)