The #274 maiden rule matches "born", which is not a maiden marker, so a regression on "Max Born" reads as intended #350

tools/differential/expected_since_1.4.0.toml's fix(#274) maiden markers consumed rule hand-copies a maiden-marker vocabulary that matches MAIDEN_MARKERS in neither direction:

name_regex = "(?i)\\b(n[ée]e|born|geb\\.?|roz\\.?)\\b"
fields     = ["maiden", "middle", "family"]

Too wide

born is in no config constant at all — not MAIDEN_MARKERS, not anywhere under nameparser/config/. The parser does not treat it as a marker:

'Jane Smith born Jones'  ->  maiden='',      middle='Smith born',  family='Jones'
'Jane Smith née Jones'   ->  maiden='Jones', middle='',            family='Smith'

So the born alternative can never match a genuine #274 change. What it can do is claim any name containing the substring born — and with fields = ["maiden", "middle", "family"], that absorbs real regressions. Max Born parses to family='Born'; a regression moving it to middle is classified as an intended change and the run exits 0.

Too narrow

13 of the 17 MAIDEN_MARKERS entries do not match the rule:

född, fødd, født, geboren, geborene, né, rozená, урожд, урожденная,
урожденный, урождённая, урождённый, 旧姓

geboren fails on the \b after geb; né is two characters where the rule needs n[ée]e. A genuine #274 diff on any of these surfaces as UNEXPLAINED — a release blocker for the wrong reason. (旧姓 is covered separately by fix(#309) in the 2.0 ledger, so it is the least urgent of the thirteen.)

Why now

#333 built the machinery. _HONORIFIC_SOURCES in tests/v2/test_regex_sync.py declares which constant each ledger alternation copies, derives the expected set from the config by script membership, and fails in both directions — an undeclared copy, and a roster key matching no rule. Extending that roster to the maiden rule is a small change.

This is also the concrete case showing unpinned ledger vocabulary does rot rather than merely could, which was the argument for #333 in the first place.

Open decisions

Two behavior questions this issue deliberately leaves open, since they are not the same call:

1. Should the born alternative be dropped from the rule (it matches nothing the parser produces), or should born be added to MAIDEN_MARKERS (making it a genuine English marker, at the cost of every surname Born)?
2. Should the rule be widened to the full vocabulary, or should the vocabulary entries with no corpus coverage stay out of it? tools/differential/README.md already notes that only 3 of the 17 maiden_markers appear anywhere in the corpora.

Found during review of #349. Not fixed there because it predates #333 and is outside that issue's scope.