A family-first name_order stops the leading particle run at the first name word

[derek73]

Implements #395: a leading never-given particle run stops at the first name word when a family-first name_order is declared. Three commits — fixture, pin, change.

                          default (unchanged)      FAMILY_FIRST          FAMILY_FIRST_GIVEN_LAST
de Mesnil Juan            family='de Mesnil Juan'  family='de Mesnil'    family='de Mesnil'
                                                   given='Juan'          given='Juan'
de la Cruz Juan Carlos    family=whole             given='Juan'          middle='Juan'
                                                   middle='Carlos'       given='Carlos'

Where it lives

Neither of the two sites that failed before. PR #391 put the claim in assign and found assign cannot split an existing piece; PR #394 put it in grouping and took four regressions. The piece is the obstacle: de la Cruz Juan Carlos groups as [de][la Cruz Juan Carlos] once the ambiguous la chains forward, so any rule stopping "after the first name word" must cut inside a piece.

post_rules can. Roles are per token, and nothing downstream reads pieces — measured, the only readers are _assign (which runs before it) and post_rules itself. So grouping stays order-independent and the 2026-08-16 keystone survives everywhere except the reach of this one fold.

The order is read, not re-derived

assign now records the order it actually used on ParseState.order, and the fold keys on that. policy.name_order would have been wrong: a script_orders entry can put the family first under a given-first policy, and the roles assign already wrote would then disagree with the roles the fold computes. The same reasoning already sits one function away, where the PARTICLE_OR_GIVEN emitter reads the role off the token rather than assuming given.

It counts units, not tokens

A conjunction join (P3) and a bound given-name pair (P5) each count once, so the stop cannot land inside one:

de la Vega y Santos Juan   ->  family='de la Vega y Santos'   given='Juan'
ibn Awf abdul Rahman       ->  family='ibn Awf'               given='abdul Rahman'
de la Cruz Juan y Eva      ->  family='de la Cruz'            given='Juan y Eva'

Both joins are read back off the tags, not the pieces — the prefix chain has already merged the joined piece into a longer one by the time the fold runs. This makes rules.md#P3's one-word clause executable, which it had no rule to demonstrate when it was written last week.

Verification, and what it is not

The differential harness reports 0 unexplained at every baseline — that is evidence for the accepted cost, not for the feature. The corpus runs under the default policy against 1.4.0, which has no name_order, so it structurally cannot see this change.

What it can see, measured against 2.1.0 with a worktree at the tag: 1 corpus name moves under each family-first order (de Mesnil Garcia → family de Mesnil, given Garcia), 0 in the default order, and the release log's "eight names under each family-first order" count is unchanged since that name was already in the eight.

The verification that counts is tests/v2/cases.py's two-leftover rows. Mutation-checked: replacing _name_positions(order, …) with a hardcoded layout that discards name_order fails exactly one row and nothing else in the suite — on master that mutant passes everything.

Commits

1. fixture — the module's reduced _LEX misclassified three words against the shipped sets: la was never-given where it ships as ambiguous (in the module whose subject is how far a particle run chains), dr was absent, md was in the wrong suffix bucket. _parsed now compares its own tagging against Lexicon.default() on every input and fails with the divergence named. It caught two of my own new tests during this PR. Also Dr. de MD Mesnil → Mr de MD Mesnil: a period makes any opening abbreviation a title by shape (H2), so the dotted title proved nothing about vocabulary.
2. pin — the two-leftover shape, in a real Spanish listing form (Apellidos Nombres keeps the particle in place; Dutch would have been wrong, since Jong, Jan Pieter de moves it behind the given name — rule P6's shape, not this one). Committed before the change, recording that all three orders agreed beforehand.
3. change — implementation, docs, release log.

Docs amended in the same diff

rules.md#P1 loses both deviates: #364 markers and gains six order-annotated examples; its "the reading holds under every declared name order" sentence is rewritten, since that is the sentence decisions.md#P1 superseded. rules.md#P2 gains the qualifier that the fold may take only part of the final group, plus an interacts: line it never had. P3 and P5 gain _post_rules.py as a second implementation site. decisions.md#P1 records where the stop lives and why, closing the question the supersession left open.

3502 tests pass, mypy clean.

Closes #395

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.53%. Comparing base (25180f5) to head (4627604).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #398      +/-   ##
==========================================
+ Coverage   98.51%   98.53%   +0.02%     
==========================================
  Files          44       44              
  Lines        2895     2942      +47     
==========================================
+ Hits         2852     2899      +47     
  Misses         43       43              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.