Two readers of SKILL.md disagreed by three, and cli-tri has been red on master for six runs

[gHashTag]

Three findings, one file.

1. Two readers of the same file, three apart

tri skill check   ->  532 numbered sections
tri skill claims  ->  535 numbered sections

skillnum.rs has five readers that walk ## N. Title headings. Three
carry the CommonMark fence rule; section_bodies and section_ranges carried
none. Three section headings in SKILL.md are quoted inside code fences as
evidence — sections about duplicate numbering that show the duplicate — and
those two readers counted them.

Fixed by one fence_toggle helper used by all five, so the next repair cannot
reach only some of them. Both now read 532.

The rule matters and is easy to get wrong. An opening fence may carry an info
string; a closing fence may not. A naive toggle on every ``` line reads
441 sections in this file — 91 fewer than the truth. I wrote that naive
toggle while investigating and it told me there were 94 phantom sections; the
real number is 3. The tests pin the distinction.

2. Three numbering collisions, and a gate that has been failing for six runs

tri skill check exits 1 on master:

section 567 appears 3 times
section 568 appears 2 times
section 567 comes after 569 -- the file reads out of order

cli-tri.yml does call it (step "No two skill sections share a number") and
has failed on master for six consecutive runs. It is not one of the four
required contexts, so nothing blocks and the corruption stays.

The duplicates are mine: concurrent branches each numbered from their own base
and the union merges kept both sides. Renumbered to 570/571/572 by line, so a
heading with matching text elsewhere could not be hit. Title set before and
after: 535 = 535, zero missing, zero invented; the diff is exactly three lines.
skill check now exits 0.

This is #3236's cost showing up as data corruption rather than CI minutes:
three sections shared a number, so "see 567" pointed at any of three things.

3. Reported, not fixed: my own lessons are filed by position, not topic

## N. Title is the numbered knowledge base (535). ### Title is a
sub-heading level (140 across 63 sections, up to 7 each) — a normal convention.

Every lesson I appended over the last several passes is a ### at end of
file, so it lands under whichever numbered section happens to be last.
Sections 567 and 568 now carry 7 and 6 sub-headings on unrelated topics.

Consequences: those lessons are not counted by tri skill claims, not
validated by tri skill check, and a reader following a cross-reference to 568
finds six unrelated lessons under it. The numbered base has not grown in
several passes despite the additions.

Not fixed here because promoting them to numbered sections is a decision about
what belongs in the base and at what granularity, and doing it silently inside
a numbering repair would be the wrong shape.

[gHashTag]

Correcting finding 3: five, not "every lesson I appended"

I wrote that "every lesson I appended over the last several passes is a ###
at end of file" and implied roughly fifteen. Measured properly on master:

140 ### sub-headings exist. Five are misplaced. The rest are legitimate.

Most ### under sections 567–572 are genuine sub-points, written inside their
parent section and on its topic — "The prototype was right for the wrong
reason" under §567 (The prototype gave the right number…), "The half of a fix
is not the fix" under §571 (X of Y where X can exceed Y…), and so on. That
is the convention working as intended, across 63 sections.

The five that are genuinely misplaced are the ones appended with
cat >> SKILL.md, which land under whichever numbered section happens to be
last at that moment:

line	lands under	actual topic
16429	§571 X of Y	the compiler was already saying it
16488	§571 X of Y	an assertion of absence and its region
16597	§572 a guard that cannot run	nineteen of my numbers re-measured
16652	§572 a guard that cannot run	a guard dead in one function, structural in the next
16701	§572 a guard that cannot run	a control that cannot fail

So the consequence I described is real but four times smaller than I said:
§571 and §572 carry two and three unrelated sub-headings, not six and seven of
them, and the numbered base is short by five, not fifteen.

The claim I got wrong was about my own working habits, which is exactly the
kind I have least reason to check and most reason to. Same defect class as
#3253: a population asserted rather than counted.