Loading
docs(specs): scope the tag-names index claims to what the plans show
Why
Two index claims in the specs are wrong now that Step 21's covering index has been built and measured.
S17's tag-read paragraph promises "an Index Only Scan with no sort node and no heap fetches" for both call shapes. The measurement says only the preview shape is sort-free. The complete shape stays index-only and keeps a sort, because WindowAgg truncates its output pathkeys to its own window's ordering and that window orders by container_manifest_id alone, so the name pathkey the index supplies is dropped above the scan. Both shapes hold inside the 100 ms budget, 45 ms and 50 ms on PostgreSQL 17.10 against 138 ms and 132 ms before the index, so the promise the budget rests on survives and the plan-shape half of it does not. The heap-fetch half comes out entirely: Heap Fetches: 0 holds in every measured run and is not a property a reader can rely on, because in a shared database a concurrent transaction holds OldestXmin back and VACUUM then cannot set the visibility map.
S12's hosted container_tags index table still lists the two-column (namespace_id, container_manifest_id) form that the same migration retires. It now names the three-column covering index and what rides it.
ADR-007's index list carries the old form too. That amendment is a handbook MR and is not in this change, per guardrail 13.
Test plan
mise run lint:docs. markdownlint and lychee report no errors on either file, and Vale reports 0 errors with its warning count unchanged from main's, 264 on S17 and 252 on S12.
Related to #1150