master red after the queen batch merge (a4e68bae): 9 stale sort seals, insertion_sort tests fail, GateScarab type conflict #6609

Since the batch of queen merges that ends at a4e68ba (#6238 and the ones before it, landed 2026-10-05 ~19:00Z), two gates have been red on master that were green before.

coverage: 9 seals newly do not hold

specs/tri/sort/{counting_sort,heap_sort,insertion_sort,tim_sort}.t27 were edited (commits 0a59572, ee34527, ed8b4a7, 9e9b95b) and their seals were not regenerated (TriCountingSort, TriHeapSort, TriInsertionSort, TriTimSort plus the sort_* twins). The ninth is tools_Wp18GateSelfConsistentSelfTest.

On the Railway t27c lab, tri seals drift --fix reseals counting/heap/tim sort and the wp18 seal. insertion_sort refuses to seal, because its own tests fail 2 of 2 (sort_basic_case, sort_simple_case). This is the same under master's compiler (13e212a) as with the #6533 fix, so the spec or its tests are wrong. The fix is to repair the spec and then reseal. Baselining it would hide the problem.

Corpus ratchet: the type-conflict ledger moved

tri types ratchet reports a NEW conflicted type name, GateScarab (ledger 84, observed 85). It most likely comes from a0749cd (SR-04 scarab-gate-five port).

Why this matters

Every PR now shows these two failures, and the failures it causes itself can hide behind them. #6599 (gen-zig) does not carry these reseals, so that its failures match master's exactly.