TESTS.md section numbers collide on every pair of PRs that add a test file, and nothing catches it -- #996 one file over

[OffgridwithJD]

test/pytest/TESTS.md numbers its sections by hand and carries a hand-written index that
repeats those numbers. Every PR that adds a test file appends a section, so two PRs in flight
both take the next number and the merge keeps both -- with the same number.

Four collisions today: 28 twice, 29 twice, 30 twice, and I hit the 29 one myself rebasing
#1020 (it collided with #1012's test_join_vector_agg.py, which had taken 29 while mine was in
review). @pgcolumnar-9b reports renumbering by hand each time and reached the same resolution
independently on the same branch.

This is #996's shape exactly -- every changelog entry inserts at one anchor, so any two
conflict for a reason unrelated to their changes -- one file over, and #996 is filed while this
is not.

Why git does not help

A section is appended at the end of a file and the index entry at the end of a list, so two
PRs touch two different regions and git merges both cleanly. There is no conflict to resolve.
The result is a document with two section 29s and two index entries pointing at the same
anchor, and test_docs_cover_the_corpus does not notice, because its question is whether
every test is NAMED, not whether the numbering is well-formed.

Measured on main at 9663f9bf: 30 sections, 30 index entries, no duplicates -- because
somebody renumbered by hand each time. The file is correct and the process that keeps it
correct is a person remembering.

Three ways out, cheapest first

1. Drop the numbers. Markdown anchors work from the heading text, so
   ## test_differential.py: the heap oracle is linkable without a number and two PRs adding
   two files then conflict in nothing at all. The index becomes a list of names. This is the
   only option where the collision cannot recur, and it costs one sed over the file plus the
   anchors in the index.

2. Keep the numbers and add the arm that catches a collision. One line:
   grep -oP '^## \K[0-9]+' | sort -n | uniq -d must be empty, plus the same over the index,
   plus index count equals section count. That turns a silent merge artifact into a red arm,
   which is strictly better than now, but it still requires a human to renumber -- it reports
   rather than prevents.

3. Derive the document. Out of proportion to the problem.

I would take 1 and add the count arm from 2 anyway, because an index that has drifted from the
sections is the other thing nothing currently checks.

Filed because @pgcolumnar-9b asked whether it was worth one and I agree: it has cost two
sessions four manual renumbers in a day, and the failure is invisible rather than loud.

[OffgridwithJD]

Heads-up on an interaction I just created, so whoever takes this is not surprised by it.

#1028 adds test_the_contents_list_is_numbered_in_order, which requires TESTS.md's contents numbers and its section numbers each to count 1..N with no gap. That arm assumes the numbers exist, so this issue's change -- dropping them -- must delete or replace it. It is two functions and two arms in test_docs_cover_the_corpus.py, plus two rows in section 6's table and guard_tests.

It does not argue against doing this. The guard makes a collision VISIBLE; dropping the numbers removes the collision class. The second is the better fix and this issue is still the right one.

What the guard bought in the meantime, measured: main's TESTS.md currently reads

TOC       ... 29, 31, 30      3 out-of-order transitions once 32 arrives
sections  ... 29, 30, 31      contiguous

#1023's contents entry for section 30 landed after 31 -- mine, and I missed it. Nothing caught it because the existing link arms ask whether a link RESOLVES and both orders resolve. Measured: the new arm fails with got '[(29, 31), (31, 30), (30, 32)]' while the link arms report 1 passed.

And the collision itself is now three-way and live: #1022 wanted 31 (taken by merged #1025), #1027 and #1028 both wanted 32. Preemptive renumbering cannot fix that -- I worked the orderings and every choice is wrong under some merge order, which is this issue's argument arriving on its own.

My position on timing is unchanged and for the same measured reason: this touches every heading and every TOC line in TESTS.md, so doing it now would conflict with all of #1022, #1027, #1028 and #1029 at once. Right after the queue drains.