Under a family-first order, should Pérez de la Vega Juan read given 'Juan'? The particle chain takes the given name, and two_family_names can't take it back #1024

When: a name is read under a family-first order with two_family_names on, and the unit after the family is a particle chain (rules/P2) that runs past the one name word its particles precede. Example: Pérez de la Vega Juan under FAMILY_FIRST.

Then: O6 takes the particle run and the one name word it attaches to as the second surname, as P1's family-first fold measures its own reach (_fold_reach). What is left is laid out by the order, as it is after any second surname O6 takes.

• Pérez de la Vega Juan, FAMILY_FIRST + two_family_names → family 'Pérez de la Vega', surname2 'de la Vega', given 'Juan'
• Pérez de la Vega Juan Carlos, FAMILY_FIRST + two_family_names → given 'Juan', middle 'Carlos', as García Márquez Juan Carlos reads
• Pérez de la Vega Juan Carlos, FAMILY_FIRST_GIVEN_LAST + two_family_names → middle 'Juan', given 'Carlos', as García Márquez Juan Carlos reads

Because: the caller has made two declarations, and the chain's reach contradicts both.

• The family-first order says the given name follows the family. decisions/P1's 2026-08-17 entry (A leading particle run should stop at the first name word when name_order is family-first #395) already reads a declared family-first order as "evidence of where the surname ends" for a particle opening the name.
• two_family_names says the family holds two names.

A chain that runs on through Juan makes the given name part of a surname that P2 says "a particle is written as part of". That surname is the one the particle precedes, Vega.

Today, where the chain is one unit:

No ambiguity is reported in any of these. O6 declines because the unit it would take (de la Vega Juan) counts as two name words. Its Except bullet states this: "A particle chain (P2) is never split, so where taking it would leave no given name the rule declines." The given name is not actually used up here; the chain has taken it.

Except:

• Taking the chain would leave no given name. Pérez de la Vega stays as it reads today (given 'de la Vega'), as O6's Except says.
• Without two_family_names nothing moves. That reach is the open question below.
• Given-first is unchanged. Pérez de la Vega Juan keeps family 'de la Vega Juan'. The chain running to the end of the name is the decided reading under the default order (decisions/P1, de Mesnil Jean reads Jean as part of the surname: the leading-particle fold takes the rest of the name #471: an order is a property of the data source).
• A family comma decides by itself (O6), so Pérez de la Vega, Juan is untouched.

Measured 2026-11-02 on the cached orcid-researchers corpus, rendered with the family box first, as decisions/O6's family-first measurement does. That rendering is not anyone's actual writing.

• Over ES, MX, CO, PE, CL, VE and AR (at most 20,000 records a country), 135,735 records have both boxes.
• 1,577 of them have a family box with a particle after its first word.
• 1,296 of those 1,577 have exactly this issue's shape: one word, a particle run, then one word.
• Read today under FAMILY_FIRST with two_family_names, 2 of the 1,577 get the family box right.
• In 1,561 of them, the given box's first word lands inside the chain in the given slot.
• By country (shape / this issue's shape / family right today): ES 383/329/1, MX 221/187/0, CO 63/62/0, PE 199/185/1, CL 142/127/0, VE 433/407/0, AR 136/116/0.

Recompute: for each record of local_agreement.records(local_corpora.load("orcid-researchers")) with country in that list and both boxes non-empty:

• A record is in the shape if Parser().parse(family).tokens has three or more words, the first without the particle tag and a later one with it.
• It is in this issue's shape if the particle run starts at the second word and is followed by exactly one word.
• Parse f"{family} {given}" under Policy(name_order=FAMILY_FIRST, two_family_names=True), and compare local_agreement.fold(.family) with fold(family).

The comparator is the same parser on the same tree, so the number is a population count and a baseline. It does not measure the change itself; re-measure on the branch.

Where the change lands:

• _take_second_family_name in nameparser/_pipeline/_post_rules.py reads the chain as one unit through _units and refuses a unit that counts as more than one name word. The fix would cut the unit at the same place _fold_reach cuts P1's run.
• rules/O6's chain bullet and rules/P2's bullet on P1's fold would be amended, and decisions/O6 would get an entry.
• The snapshot parses the default policy, so it should not move. local_agreement.py orcid-researchers --base is the check.

Open questions:

1. Should the chain's reach depend on the order even without two_family_names? That would make P2 stop after one name word under any family-first order, as P1's fold does.
   • Pérez de la Vega Juan under FAMILY_FIRST would read given 'de la Vega', middle 'Juan'.
   • It would move every family-first parse of this shape, including Vietnamese names with Van in the middle (Nguyen Van Thanh Long reads given 'Van Thanh Long' under both family-first orders today).
   • Those need measuring before deciding, and this issue does not decide it.
2. Should the default family-first reading report the chain it calls? No ambiguity is reported today.

Related: #1022 (the per-surname particles and base, which leans on O6's units), #670 and #828 (a particle opening a family-first name), #368 (where a mid-name chain is positioned under family-first, decided 2026-08-16), #395 (P1's family-first reach).