docs: replace "Nothing breaks." with a check the reader can run

The claim was contradicted by the 2.0 removals list. Worse, it was
unfalsifiable -- it gave a reader no way to find out whether their own
code was affected.

Replace it with the actual promise: if your suite runs clean on 1.4
under -W error::DeprecationWarning, it runs on 2.0. Verified against a
live 1.4.0 -- 11 of the 15 removals do warn there.

Name the four that do not, in a new "Before you upgrade" section:
regexes assignment (including the CONSTANTS.regexes.bidi = False recipe
1.3.1 itself recommended), *_list assignment, positional Constants(),
and subclass parsing-hook overrides. All four raise or warn on contact,
so the reader meets them immediately.

Call out separately the one removal that changes results in silence:
HumanName.__eq__ is gone, so name == "John Smith" is now False. It
warned on 1.4 and says nothing on 2.0, making it the only way to get a
wrong answer without being told.

Also drop "or never" from the migration framing -- the compatibility
layer is removed in 3.0, as the next sentence says.

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

Author: derek73

README.rst

@@ -44,11 +44,16 @@ Learn more
 Coming from 1.x
 ----------------
 
-Nothing breaks. 2.0 keeps ``HumanName`` and ``CONSTANTS`` working exactly
-as before — same imports, same attributes, same mutation API. See
+``HumanName`` and ``CONSTANTS`` keep working in 2.0 — same imports, same
+attributes, same mutation API. What 2.0 removes is the batch of
+deprecations 1.3 and 1.4 announced, so if your test suite runs clean on
+1.4 under ``python -W error::DeprecationWarning``, you are nearly done.
+Two things that check will not catch: four removals 1.4 never warned
+about, which all raise on contact, and one that changes results silently
+— ``name == "John Smith"`` is now ``False``.
 `Migrating from HumanName <https://nameparser.readthedocs.io/en/latest/migrate.html>`__
-for translating a v1 customization into the new API, whenever that's
-convenient for you.
+covers both, and translates a v1 customization into the new API whenever
+that's convenient for you.
 
 See the `release log <https://nameparser.readthedocs.io/en/latest/release_log.html>`__
 for the full list of changes in the 2.0 series.

docs/migrate.rst

@@ -1,13 +1,12 @@
 Migrating from HumanName
 =========================
 
-Nothing breaks. 2.0 keeps ``HumanName`` and ``CONSTANTS`` working
-exactly as before — same imports, same attributes, same mutation API
-(``name.C.titles.add(...)``, ``name.first = "..."``, and so on).
-Upgrading to 2.0 and migrating your code to the new
-:class:`~nameparser.Parser`/:class:`~nameparser.Lexicon`/
+``HumanName`` and ``CONSTANTS`` keep working in 2.0 — same imports,
+same attributes, same mutation API (``name.C.titles.add(...)``,
+``name.first = "..."``, and so on). Upgrading to 2.0 and migrating your
+code to the new :class:`~nameparser.Parser`/:class:`~nameparser.Lexicon`/
 :class:`~nameparser.Policy` API are two separate decisions — you can do
-the former today and the latter whenever it's convenient, or never. The
+the former today and the latter whenever it's convenient. The
 compatibility layer (``HumanName`` and ``nameparser.config``) is
 removed in 3.0; that release is not scheduled.
 
@@ -19,6 +18,34 @@ This page exists for the other direction: translating a v1
 customization or a v1-shaped comparison into the 2.0 API, one row per
 old name.
 
+Before you upgrade
+------------------
+
+What 2.0 removes is the batch of deprecations 1.3 and 1.4 announced. If
+your test suite runs clean on 1.4 under ``python -W
+error::DeprecationWarning``, it will run on 2.0 — with four exceptions
+that 1.4 never warned about, each of which fails loudly the first time
+you hit it:
+
+* ``CONSTANTS.regexes.<name> = ...`` raises ``TypeError``. This includes
+  ``CONSTANTS.regexes.bidi = False``, the opt-out 1.3.1 recommended for
+  keeping bidirectional marks; the 2.0 spellings are
+  ``Policy(strip_bidi=False)`` and ``Policy(strip_emoji=False)``
+* assigning a ``*_list`` attribute (``name.first_list = [...]``) raises
+  ``AttributeError`` — the lists are read-only snapshots in 2.0
+* positional ``Constants(...)`` construction raises ``TypeError``; the
+  constructor is keyword-only
+* a subclass overriding a v1 parsing hook (``pre_process``,
+  ``parse_pieces``, ``is_title``, and the rest) gets a
+  ``DeprecationWarning`` at construction naming the hooks it overrode,
+  because 2.0 delegates parsing to the core parser and never calls them
+
+One removal changes results without saying anything. ``HumanName`` no
+longer defines ``__eq__``, so ``name == "John Smith"`` is now ``False``
+where 1.x returned ``True``. That one *did* warn on 1.4, but nothing
+will tell you on 2.0. If you compare names anywhere, grep for ``==``
+before upgrading and move to ``matches()`` — see `Comparison`_.
+
 Attribute map
 -------------