Use letter case to disambiguate suffix vs. surname: "Jack MA" vs "Jack Ma"

[derek73]

Four post-nominals in suffix_acronyms_ambiguous are also ordinary surnames: do, ed, jd, ma. The parser decides between the two readings by position — an ambiguous acronym is a credential when removing it still leaves a given and a family name, and a surname otherwise:

>>> parse("Jack MA").family
'MA'
>>> parse("John Smith MA").suffix
'MA'

That rule works well, but it throws away a signal the input already carries. Letter case is currently ignored entirely — these parse identically today:

>>> parse("Jack MA").family,       parse("Jack Ma").family
('MA', 'Ma')
>>> parse("John Smith MA").suffix, parse("John Smith Ma").suffix
('MA', 'Ma')

Yet MA and Ma read very differently to a person. In "Jack MA", all-caps suggests a degree; in "John Smith Ma", title case suggests a surname. Both are cases where the positional rule and the case signal disagree.

The constraint that makes this non-trivial: case is only informative when the input as a whole varies in case. JOHN SMITH MA and john smith ma come from all-caps and all-lower data sources, where case carries no information at all — and a lot of real name data looks like that. So this can't be a hard rule; it would have to be a tiebreaker consulted only when the string shows mixed case, which the parser would need to determine first.

Sketch, if it's worth doing:

• decide whether the input is uniformly cased (all upper, all lower) or mixed
• only for mixed-case input, let an all-caps ambiguous acronym lean credential and a title-case one lean surname
• keep the positional rule as the fallback whenever case is uninformative

This stays deterministic — no model, no training data — so it doesn't conflict with the parser's guarantee that the same input always parses the same way.

Came out of the 2.0 work on the positional rule (8147ac6); capitalized() already reasons about single-case vs mixed-case input, so some of the detection logic exists.

[derek73]

A second position where case would decide it: the post-comma given slot.

"Smith, MA" puts MA in given, and case is ignored there too:

>>> parse("Smith, MA").given, parse("Smith, Ma").given, parse("Smith, ma").given
('MA', 'Ma', 'ma')

All three take the same path — the first post-comma piece becomes the given name before any suffix test runs. "Smith, Ma" is plausibly a person; "Smith, MA" is more plausibly a surname followed by a stray credential, and "Smith, ma" is probably neither.

This came up while deciding whether the parser should report an Ambiguity for the post-comma case. It doesn't, deliberately — a comma usually settles the structure, and flagging it would be noise on ordinary input. But if case ever becomes an input to the decision, this position is a second place it would apply, alongside the trailing-acronym case above.

Not proposing a change to the parse today: "Smith, MA" is unusual input, and any special handling here should be case-sensitive rather than firing on all three spellings.