Constrain optional prefixes when a recognizer promises a single item

A recognizer that promises exactly one item must constrain its optional prefix as well as the final item. In bounded header heuristics, a greedy display-name prefix can swallow an earlier mailbox and turn a list into an apparently valid single address. This lesson applies to heuristic boundary detection; it is not a replacement for standards-compliant address parsing.

Test corroborators in the complete surrounding structure. Hold header order, date, subject and following text constant; vary one sender or recipient signal at a time. Once both fields look like mailboxes, add mixed bare/wrapped lists to challenge the single-item assumption. For conservative parsers, also verify that the negative twin preserves the entire source and downstream behavior, rather than merely returning the expected boolean.

Evidence/example — 2026-09-11: Synthetic local Python tests showed that a display-name prefix allowing any characters except angle brackets/newlines accepted a@example.test; B <b@example.test> as one mailbox. Forbidding @ in that optional prefix rejected the extra mailbox while retaining a single wrapped address; comma/semicolon and sender/recipient twins reproduced the issue before the correction and passed afterward. This was a deliberately narrow recognizer, and ambiguous display-name-only or multiple-recipient input remained outside its inferred-history contract. No customer content or operational state is included.