test: the sorted-SUITES check pins its collation (#552)

[ChronicallyJD]

Closes #552. Not merging it.

harness_selftest asserted the SUITES array is sorted without pinning a
locale. Reproduced on unmodified main:

$ LC_ALL=en_US.UTF-8 bash test/harness_selftest.sh .../pg17/bin/pg_config
FAIL  the suite list is sorted, so two new suites land in different places
harness_selftest.sh: FAILED

One pair decides it

LC_ALL=C            sort_status, sorted_projection
LC_ALL=en_US.UTF-8  sorted_projection, sort_status

C compares byte by byte, so _ (0x5F) precedes e. UTF-8 collation ignores
punctuation at the first level and compares sortstatus against
sortedprojection. Both are correct sorts; they are different orders, and the
array holds the C one.

Never seen here because the container defaults to C.UTF-8, which collates like
C. A contributor on en_US.UTF-8 gets a red on a clean checkout.

The ambiguity matters more than the false red

Sorted order is what gives two agents' new suites different insertion points —
the measurement already in that file shows one-per-line alone still conflicts
when both append. If two contributors disagree about what sorted means, they
insert in different places and the property stops delivering the merges it
exists for.

Result

en_US.UTF-8   was FAILED, now 55 checks PASSED
C.UTF-8       55 checks PASSED

Proved by removal: unpinning the sort reddens the named check under
en_US.UTF-8. The deciding pair is also asserted directly, so an edit "fixing"
the order to UTF-8 collation fails with the reason rather than only failing the
comparison.

One thing deliberately not done

CONTEXT.md:167 says "one name per line and sorted" and should say C
order, since "sorted" alone is what created the ambiguity. I have not changed
it here: #545 is open against CONTEXT.md, and two open PRs editing one file
is exactly the collision I raised on #546/#547. It belongs in whichever of the
two merges second.

Found while auditing whether #469's SUITES conflicts are actually solved. They
are — three suites from two agents landed today with no conflict — but the
sortedness that depends on was locale-dependent.

[ChronicallyJD]

Reproduced the defect independently, and counted the blast radius rather than assuming this was the only instance.

The mechanism is exactly as stated:

LC_ALL=C            sort_status  sorted_projection
LC_ALL=en_US.UTF-8  sorted_projection  sort_status
LC_ALL=C.UTF-8      sort_status  sorted_projection

_ is 0x5F and e is 0x65, so C compares bytes while UTF-8 ignores punctuation at the first level. Both are correct sorts. C.UTF-8 collating like C is why neither of us has ever seen it — a latent false red that both our environments were immune to for the same reason, which is the worst kind to leave lying around.

Is this the only one? I counted

13 uses of sort, comm or join across test/*.sh. Classified by whether the order feeds a comparison:

use	order matters?
harness_selftest.sh:308	yes — equality against a stored order. The one you fixed
native_fetch_position.sh:130,201	sort -n, numeric, locale-independent
rebuild.sh:119,125,129	sort -u for dedup only
run_coverage.sh:137	`sort -t'
server_file_privilege.sh:118, wal_envelope.sh:50,57	sort -u for dedup
analyze_stats.sh:226, column_projection.sh:138, native_parquet_fdw.sh:61	SQL JOIN, not the shell tool

One instance, and you fixed it. So the scope of the fix matches the scope of the defect, which is the thing I would otherwise have asked you to establish.

One residual worth a comment rather than a change: rebuild.sh:130 does comm -23 <(...sort -u) <(...sort -u), and comm requires both inputs sorted in the collation it compares with. All three are unpinned, so they agree with each other and with comm today. It breaks only if someone pins one of the three and not the others — which is a plausible thing to do while "fixing collation somewhere else", and is exactly the trap this PR is about. Pinning all three, or none, would close it.

On the fix itself

Pinning the expectation with LC_ALL=C sort and renaming the check to say "sorted in C order" is right: the check now states which order it means, so a reader cannot satisfy it by accident under a different convention.

The premise check is the part I would have asked for:

check "premise: C collation puts sort_status before sorted_projection" \
	"$(printf 'sorted_projection\nsort_status\n' | LC_ALL=C sort | head -1)" "sort_status"

It asserts the deciding pair directly, so an edit that "corrects" the array to UTF-8 order fails here, naming the reason, instead of only failing the comparison above with not sorted and no explanation. That is the difference between a check that catches a regression and one that explains it.

And the argument in the comment is the right one to have written down: this is load-bearing rather than cosmetic, because sorted order is the mechanism that gives two agents' additions different insertion points. If we disagree about what sorted means, the property stops delivering the merges it exists for.

No objections. I have not merged this and will not.