parse("Andrew") reports no ambiguity, but given-or-family is a guess

[derek73]

A name with exactly one name word carries no information about which field that word belongs to. The library reads it as the given name so the same input always reads the same way — a convention, not a determination — and reports nothing:

parse("Andrew").given        # 'Andrew'
parse("Andrew").ambiguities  # ()

rules.md#A1 already sets the contract this falls under: "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." This is such a case and carries none. AmbiguityKind has seven members and no given-or-family fork; PARTICLE_OR_GIVEN is the shape one would follow.

The hard part is the condition, not the report

mechanisms.md#AMBIGUITY-AT-THE-DECISION-SITE requires a fork to fire where the outcome was chosen, not where the code arrived — its recorded failure is a fork reported for all 39 ambiguous particles on "Dr. Van Jr." on the weaker test.

"Exactly one name word" is the weaker test. Measured over the 1,085 differential corpus names, a naive lone given word, nothing else decided it condition fires on 19:

Andrew · abdul · de                        <- the actual subject: one word, no information
Duke of Edinburgh · Duke of Wellington     <- a particle join; the lone "name word" is a joined unit
Dean of Chemistry · John of the Doe
John & Jane · Juan and Garcia · e and e    <- conjunction joins
, John                                     <- a comma name

Only three or four are the case this issue is about. The rest have real structure in the input — particles, conjunctions, a comma — and the parse made a decision about them; they merely end up as a single unit afterwards. A fork there would cry wolf.

So the condition wanted is closer to "no vocabulary, no structure and no rule contributed to this reading" than to a word count, and working that out is the substance of the issue.

Where it must not fire

Every rule that carves an exception from the lone-word convention has decided the word, so none of these is a guess:

input	decided by	fork?
Andrew	nothing	yes
Dr. Smith	H1	no
'Smitty' Smith	N3	no
Sir John	H1's given-name-title carve-out	no
Smith née Jones	M4 (#445)	no

Note #445 reduces this issue's population: it turns a class of guesses into determinations. Measure the fork's reach after #445 lands, not before.

Also worth weighing

• A new AmbiguityKind member is a public enum addition, so it is a compatibility surface in a way a parse fix is not.
• A bare one-word name is a common input. A new fork on it reaches every caller reading .ambiguities, and the differential gate reports ambiguity changes, so the blast radius should be measured before the reading is chosen.

Raised by Derek on #445: "given or family is really a guess. we have no information, it could be either. we pick one to be consistent." #445 records that framing in rules.md#O5 — the convention is written as a convention — so adding the report later changes behavior against a rule that already describes the doubt rather than contradicting one that denied it.