Case-table bookkeeping: 29 CJK honorific rows are classified single-issue where they depend on #271 too

[derek73]

Two small accuracy problems in tests/v2/cases.py, both pre-existing, both found during the #320 review.

1. cases.py and expected_changes.toml disagree about compounds

tools/differential/expected_changes.toml describes the CJK honorific rules as compounding with the #271 order flip — seven rules use that language. tests/v2/cases.py labels the same rows single-issue (fix(#307), fix(#308)).

Compound notation exists and is already used — feat(#273) + fix(#271), twice, in the nickname block for precisely this shape (one issue enables, #271 orders). So the honorific block is inconsistent with both the toml and its own table's precedent.

Rows like ko_honorific_ssi (김민준 씨) depend on #271's segmentation and family-first order to reach their asserted fields, and say fix(#307) alone. fix(#271) + fix(#307) would be strictly more honest.

This is a block-wide sweep rather than a one-row edit, which is why #320 left it alone rather than fixing one row into a different inconsistency.

2. ko_honorific_after_comma's note names the wrong gate

The note says "the post-comma lenient gate admits the honorific too". The gate is _group._is_suffix_piece, not is_suffix_lenient — demonstrably, since before #320 is_suffix_lenient("씨.") was already True and 씨. still went to given.

Neither item affects behavior; both mislead a reader tracing why a row lands where it does.

[derek73]

Part 2 (the wrong gate name) is fixed on master in 88ca0b3. Part 1 remains, and the issue is retitled to cover only it.

Recording that part 2's repro no longer reproduces. The issue argued the gate was misnamed because "before #320, is_suffix_lenient("씨.") was already True and 씨. still went to given". #320 has since landed and 김민준, 씨. now gives suffix 씨., so anyone trying that demonstration will not see it.

The conclusion was right anyway, by a negative control instead:

김민준, 씨                      →  family 김민준, suffix 씨
김민준, 태호                     →  family 김민준, given 태호      ← default post-comma reading
lenient_comma_suffixes=False   →  row unchanged                ← so the lenient gate is not what admits it

씨 classifies with vocab:suffix + vocab:suffix-word, the structure is FAMILY_COMMA, and _group._is_suffix_piece (_group.py:72-79) diverts the single-token piece out of the given-name position. lenient_comma_suffixes is not on the path.

Worth keeping in mind for part 1: the wrong name was plausible because both gates are real, both concern suffixes, and both sit on the post-comma side — the note described the mechanism that genuinely handles the neighbouring Latin case (John Ingram, V). Checking these by reading will not separate them; flipping the policy the claim depends on will.

Scope of what's left. 29 rows carry classification="fix(#307)" or "fix(#308)"; 2 rows in the whole table use compound notation today, both in the nickname block. So this is not 29 typos — it is a convention that never propagated out of the block where it was invented. It wants a stated rule (every row whose asserted fields depend on #271's segmentation and its order flip gets fix(#271) + ...) applied as a sweep, with the dependency measured per row rather than assumed from the row's shape. Fixing rows one at a time creates a third inconsistency, which is why #320 declined to.