harness_selftest.sh is the new SUITES line: three open PRs all append at line 667 and conflict pairwise

[ChronicallyJD]

test/harness_selftest.sh has become the new SUITES line, and it says so in
its own comments without anyone noticing it applies to the file itself.

Measured on the current board

Every open PR merges onto main cleanly on its own. The conflicts are all
pairwise, and four of them land in one file:

harness_selftest.sh on main: 670 lines

  #544  adds at line 667     <- end of file
  #549  adds at line 667     <- end of file
  #551  adds at line 667     <- end of file
  #553  adds at line 305     <- middle

Cumulative merge in a plausible order:

#538 ok   #543 ok   #545 ok   #546 ok
#547 CONFLICT  columnar_reader.c columnar_tableam.c columnar_vector.c
#550 CONFLICT  columnar.h + 6 more
#544 ok
#549 CONFLICT  test/harness_selftest.sh
#551 CONFLICT  test/harness_selftest.sh test/lib.sh
#553 ok

#553 is the control. It is the only one of the four that edits the middle of the
file, and it is the only one of the four that merges clean.

The file already documents this exact failure

From harness_selftest.sh itself, the measurement that motivated sorting
SUITES:

one line,     both additions on the same line          CONFLICT
one per line, both appended at the end                 CONFLICT
one per line + sorted, names far apart                 clean
one per line + sorted, names that sort adjacently      CONFLICT

Row two is what three of these four PRs are doing. The fix that was applied to
SUITES — give an addition an insertion point decided by its content rather than
by "the end" — was never applied to the file that argues for it.

Why it is worth fixing rather than resolving each time

Two agents are adding checks to this file continuously, and each new check block
conflicts with every other new check block. It is not a hard conflict to resolve
— the hunks are adjacent appends — but it is a conflict per pair per PR, it has
to be resolved by whoever merges second, and the resolution is the kind that
looks trivial and can silently drop a block.

Possible shapes

Not proposing one, because this wants a decision rather than a patch:

• Named sections in a fixed order, with new checks inserted by topic, which is
  the direct analogue of sorting SUITES.
• Split the file. It is 670 lines and covers ports, suite registration, build
  status, the fatal pattern and the cluster-start path. Those are separable, and
  separate files do not collide at all.
• Accept it and note in CONTEXT.md that additions go in a named section
  rather than at the end.

Found while checking whether the current queue of ten open PRs can be merged as a
set. It can, in an order, with rebases — this is the part that makes the rebases
necessary.