docs: record the vocabulary data corrections in the release log

esq and the TITLES trailing spaces do not change any parse, so the
entry says so plainly -- but membership tests against the exported
constants do change, and "'actor' in TITLES" flipping from False to
True is the kind of thing someone's code could depend on either way.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: derek73

docs/release_log.rst

@@ -59,6 +59,7 @@ Release Log
     - Change the 2.0 API's default ``render()``/``str()`` spec to show every non-empty field: ``'{title} {given} "{nickname}" {middle} {family} ({maiden}) {suffix}'``. The quoted nickname round-trips exactly; the parenthesized maiden re-parses as a nickname, a deliberate choice of presentation over lossless round-trip -- use ``née {maiden}`` in a custom spec if you need it to survive a reparse. ``HumanName`` keeps v1's own ``string_format`` default, unchanged
     - Change delimiter-overlap precedence in the 2.0 API: a pair listed in ``Policy.maiden_delimiters`` is dropped from the effective nickname set, so ``Policy(maiden_delimiters={("(", ")")})`` alone routes parenthesized content to ``maiden``. The default nickname set is exported as ``DEFAULT_NICKNAME_DELIMITERS``. ``HumanName`` keeps v1's nickname-wins precedence, so no existing behavior changes
     - Change suffix-delimiter rendering when a custom suffix delimiter is configured: for ``suffix_delimiter="/"`` and ``"John Smith, RN/CRNA"``, 1.x split the token and rendered ``suffix="RN, CRNA"`` where 2.0 keeps it whole as ``"RN/CRNA"``. Role assignment is unchanged; only rendering differs
+    - Correct two errors in the shipped vocabulary data that 1.x carried: ``esq`` was listed as both a suffix acronym and a suffix word (it is a word), and ``actor`` and ``television`` had trailing spaces in ``TITLES``, so ``"actor" in TITLES`` was ``False``. **Parse output is unchanged** in both cases -- the parser normalizes entries on ingest and tests suffix words first, which is exactly what let the errors go unnoticed -- but code that tests membership against the exported constants directly will see corrected results. The data modules now assert these invariants at import time, alongside the ones ``prefixes.py`` already checked
 
     **International name support**