`Mc Donald` and `Ste Marie` read the particle as the given name

[derek73]

Two abbreviation particles are in the may-be-given half of the particle vocabulary, so a name that opens with one is read as having a given name:

Mc Donald    given='Mc'   family='Donald'   ambiguity: particle-or-given
Ste Marie    given='Ste'  family='Marie'    ambiguity: particle-or-given

Both should give the whole name as the surname (family='Mc Donald', family='Ste Marie'), which is what membership in NON_GIVEN_NAME_PARTICLES produces. Neither Mc nor Ste is a standalone given name in any culture — they are contractions of Mac and Sainte.

Note this is the default name order, so it is a live misparse today, independent of #359.

Three words, three different answers

Raised as "mc, st and ste have no vowels so cannot be given names". Measured, the vowel heuristic is a good instinct but not the actual criterion:

• mc — move it. Live misparse above. It is also in SUFFIX_ACRONYMS (MC, Master of Ceremonies), but that is trailing position and unaffected: John Smith MC still gives suffix='MC'.
• ste — move it. Live misparse above, and it has a vowel — so the criterion that actually works is "abbreviation of a word that is never itself a name", not the vowel shape.
• st — moving it changes nothing. st is in TITLES, and title handling consumes a leading match before particle logic runs:

  St Clair    title='St'  given=''  family='Clair'
  

  Mid-name is already correct (Jean St Clair -> family='St Clair'). Whether title='St' is the right reading for a leading St is a separate question worth its own issue if anyone cares.
• mac — leave it. Same shape as mc, but Mac is a real given name, so it belongs in the may-be-given half. This is the case that shows the vowel test is doing real work.

Joined spellings are single tokens and unaffected either way (McDonald, StClair).

The wider question behind it

Only 9 of the 39 may-be-given members were ever individually justified in the NON_GIVEN_NAME_PARTICLES docstring: al, van, von, della, di, del, da, vander, abu. The other 27 are there by the docstring's stated conservative default — "When unsure, leave a word out: a missing member just means that name is not auto-fixed, whereas a wrong member misparses a real person."

So the split was never exhaustively curated, and mc/ste are not a one-off oversight so much as the first two cases anyone has looked at closely.

Same-shape candidates worth examining: aan, aen, heer, freiherr, freiherrin, te, tho, thoe, vel, vande.

Words in that list that genuinely ARE given names and must stay put: bar (Bar Refaeli — the docstring's own Hebrew note cites exactly this), le, do, bin, mac.

The evidence standard is the docstring's: a wrong never-given member misparses a real person, a missing one merely leaves a name un-auto-fixed. So each word needs a reason to move, not an absence of a reason to stay.

Scope note

This changes default-order parsing, which is a wider blast radius than #359 (which only affects name_order=FAMILY_FIRST). Worth its own commit and its own tools/differential run so the numbers attribute to a cause rather than arriving as one lump.

Split out of #359 to keep that PR scoped.

[derek73]

Dependency worth knowing before moving words out of the ambiguous set.

_group's PARTICLE_OR_GIVEN emitter — the branch that reports a particle chained onto the following piece — needs a leading piece that is both a title and an ambiguous particle. Since #367 that is the only shape reaching it, because an ordinary title is now transparent to the leading-particle exception and takes _assign's branch instead.

That intersection is exactly three words today:

titles & particles_ambiguous  ->  ['do', 'freiherr', 'st']

Two of them (freiherr, st) are on this issue's candidate list. st is listed here as moot for the leading position because TITLES claims it first — true for the parse, but moving it still removes it from particles_ambiguous and so from this intersection.

PR #370 adds tests/v2/test_parser.py::test_the_chained_emitter_is_still_reachable, which fails in two distinguishable ways:

• the word this issue moves is gone from the set — the message prints what is left, e.g. need a lead from ['do', 'st'], and the five emitter tests just need a different lead
• the set is empty — the emitter is unreachable, every test of it is measuring nothing, and the right move is to delete the emitter rather than repoint its tests

So moving one or two of the three is cheap and self-explaining. Moving all three is a decision about whether _group's emitter should still exist, and the test will say so rather than leaving a green suite over dead code.