A tussenvoegsel attachment decides a particle-or-given fork and reports no ambiguity, which A1 requires #405

rules.md#A1 says a genuinely uncertain reading completes on the best branch and reports the doubt:

where the text's structure or a word's reading is genuinely uncertain, the parse completes on the best reading and carries an ambiguity report naming the doubt

P6's tussenvoegsel attachment (#379) creates exactly such a fork and reports nothing:

Van Johnson        ambiguities=('particle-or-given',)   "leading 'Van' may be a family-name particle"
Nguyen, Thi Van    ambiguities=()                       family='Van Nguyen' -- same word, same fork
Berg, Jan vd       ambiguities=()                       family='vd Berg', taken from suffix

rules.md#P6 now documents the uncertainty in its own Accepted: block — the ASCII spelling of a Vietnamese name is the same string as the Dutch listing — so the rule asserts the condition A1 attaches a report to, and no report is emitted.

Why it is not emitted today

nameparser/_pipeline/_assign.py:326 records a deliberate scoping:

PARTICLE_OR_GIVEN is deliberately not emitted here: after a comma the family is already fixed, so a leading given-position particle is not meaningfully ambiguous.

That reasoning was sound when written and does not cover the new fork. The comma fixes which piece is the family; it says nothing about whether the trailing particle belongs to it. P6 decides that separately, and it is genuinely uncertain.

What it would take

The fork is decided in post_rules, which today owns only {tokens} in the stage-ownership map (tests/v2/pipeline/test_state.py). Emitting from there means adding ambiguities to its ownership — consistent with the map's own stated principle, since ambiguities are "recorded by every stage that DECIDES one … a fork whose branches are taken in different stages needs an emitter in each", which is why group and assign both emit PARTICLE_OR_GIVEN already.

Scope note: only the ambiguous half of the vocabulary is a fork. A never-given particle (de, der) cannot be a name, so "Jong, Piet de" is not uncertain and should stay silent. The words that would report are the ambiguous particles and the three dual-vocabulary words (vd, mc, do).

Why it matters

A caller processing mixed Dutch and Vietnamese listings currently has no programmatic tell that family="Van Nguyen" was a coin flip. That is the one thing the ambiguity surface exists to provide, and it is the only mitigation available for a collision the parser genuinely cannot resolve — the diacritic separates the two readings when it is present ("Nguyễn, Thị Vân" parses correctly), but the ASCII transliteration is the same string in both traditions.

Found by review of #403.