docs: fix what the review of the usage.rst subheadings found

Links and placement:
- The leading-particle "see name-order" landed on a section that never
  discusses leading particles; it now targets "Where the vocabulary
  answers first" (labeled order-vocabulary-first), and "Family-first
  name order"'s own "noted at the end of this section" -- wrong before
  this PR, the exceptions being in the next section -- links there too.
- The sentence about the whole attachment table had landed under the
  leading-particle subheading; it moves above it, and "covered next"
  becomes a link, the East Asian section no longer being next.
- "That default is built for display" opened the new "Surviving a
  reparse" with no antecedent, which is also where the maiden-roundtrip
  link lands; it names the str() rendering now.
- The Shakespeare example moves beside the paragraph it illustrates,
  and 王·Smith, the case the boundary paragraph is about, gets one.
- The ambiguous-words pointer's colon introduced a doctest showing no
  comma rules; the pointer moves after the doctest.

Claims narrowed or broadened by the move:
- "two or more words before it" drops "words to spare"'s meaning: a
  title does not count ("Dr. John ma" keeps the surname). Fixed here
  and in customize.rst's identical bullet from #588.
- "A word in Han, kana or hangul" read as wholly CJK; a word CARRYING
  such a character escapes the title reading ("田中x. Smith").
- "Every piece of each is optional" had widened from forms 1-3 to all
  seven (form 7's divider is not optional); it is scoped back.
- The Particles bullet read as a fourth view; it is capitalized()'s
  second exception and merges into that bullet.
- The facade parenthetical claimed initials() takes capitalized()'s
  whole fallback; it asks only the conjunction question (measured:
  J. S. for a spliced "y e"), and "only capitalized() is handed a
  vocabulary" is restored.

Also: "East Asian forms" renamed "Forms the script carries" to match
its condition-named siblings, a double blank line removed.

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

Author: derek73

docs/customize.rst

@@ -300,7 +300,8 @@ The full reading of a bare marked acronym, in order:
   the family name even WITH words to spare (``"John Smith Ma"``).
 - **No signal** — all lowercase in a mixed-case name, or any spelling
   in a name written wholly in one case — falls back to the count: a
-  suffix with two or more words before it (``"John Smith ma"``), the
+  suffix with two or more name words before it, a title not counting
+  (``"John Smith ma"``), the
   family name otherwise (``"JACK MA"``).
 - **After a comma** the count of name words before the comma decides
   FIRST, and the case is read only where the count leaves the word a
@@ -576,8 +577,8 @@ Family-first name order
 
 ``name_order`` is the one most likely to matter for data that is not
 in Western order. Positional input is assigned in the order you
-declare — with the two vocabulary exceptions noted at the end of this
-section — so a name written family-first — Hungarian, here — parses as
+declare — with the two vocabulary exceptions noted under
+:ref:`order-vocabulary-first` — so a name written family-first — Hungarian, here — parses as
 written instead of needing to be rearranged afterwards:
 
 .. doctest::
@@ -717,6 +718,8 @@ family-first orders differ from each other:
     >>> given_last.parse("de la Cruz Juan Carlos").middle
     'Juan'
 
+.. _order-vocabulary-first:
+
 Where the vocabulary answers first
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

docs/usage.rst

@@ -32,12 +32,13 @@ Input shapes
 -------------
 
 Three arrangements are understood by default, two more when you
-declare a family-first order, and two more by script alone. Every piece
-of each is optional.
+declare a family-first order, and two more by the script they are
+written in.
 
 Understood by default
 ~~~~~~~~~~~~~~~~~~~~~
 
+Every piece of each is optional:
 
 1. ``Title Given "Nickname" Middle Middle Family Suffix``
 2. ``Family [Suffix], Title Given (Nickname) Middle Middle[,] Suffix [, Suffix]``
@@ -71,8 +72,8 @@ displaced from the family name it belongs to; form 5's trailing word
 is the given name by the caller's declaration, so there is nothing
 there to reinterpret.
 
-East Asian forms
-~~~~~~~~~~~~~~~~
+Forms the script carries
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 Two more arrangements are native East Asian forms and need no
 ``name_order`` at all — the script itself carries the reading:
@@ -153,6 +154,12 @@ names together as easily as two surnames:
     >>> parse("Juan de la Vega y Rodriguez").family
     'de la Vega y Rodriguez'
 
+One shipped vocabulary works the other way round and so is not in the
+table above: :mod:`surnames <nameparser.config.surnames>` *splits* a
+word instead of merging two, and is covered under `East Asian names`_.
+:doc:`customize` covers how to change which words are in each of these
+sets.
+
 A particle at the start of a name
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -161,9 +168,9 @@ at the start of a name. It has no surname to attach to yet, so what
 decides the reading is whether it is one that can double as a given
 name: the particle either becomes the given name or turns the whole
 name into a surname. Only the first of those is ``name_order``'s
-question — see :ref:`name-order`, and read the given name below as the
-default given-first order's — since a particle that can never be a
-given name is the surname whatever order you declare:
+question — see :ref:`order-vocabulary-first`, and read the given name
+below as the default given-first order's — since a particle that can
+never be a given name is the surname whatever order you declare:
 
 .. doctest::
 
@@ -183,12 +190,8 @@ comma is the given name:
     >>> parse("de Mesnil, Juan").given
     'Juan'
 
-:doc:`customize` covers how to change which words are in each of these
-sets, and :ref:`ambiguous-words` which particles may double as given
-names. One shipped
-vocabulary works the other way round and so is not in the table above:
-:mod:`surnames <nameparser.config.surnames>` *splits* a word instead of
-merging two, and is covered next.
+:ref:`ambiguous-words` covers changing which particles may double as
+given names.
 
 .. _east-asian-names:
 
@@ -262,7 +265,13 @@ token separator when it sits between classified-script characters
 qualifies), and a dot anywhere in the name reads the whole name as a
 transcription listing: it keeps the order it was written in and is
 never segmented — the role pure katakana plays for Japanese
-transcriptions, played here by the divider instead of the script.
+transcriptions, played here by the divider instead of the script:
+
+.. doctest::
+
+    >>> shakespeare = parse("威廉·莎士比亚")
+    >>> shakespeare.given, shakespeare.family
+    ('威廉', '莎士比亚')
 
 Because only classified characters on both sides make it a divider,
 the same codepoint interior to a Latin-script name — the Catalan punt
@@ -272,11 +281,10 @@ undivided:
 
 .. doctest::
 
-    >>> shakespeare = parse("威廉·莎士比亚")
-    >>> shakespeare.given, shakespeare.family
-    ('威廉', '莎士比亚')
     >>> parse("Gal·la Puig").given
     'Gal·la'
+    >>> parse("王·Smith").given
+    '王·Smith'
 
 The Japanese middle dot ・ (covered next) is a different mark carrying
 a different convention, and keeps its own reading.
@@ -684,7 +692,8 @@ family name:
 Surviving a reparse
 ~~~~~~~~~~~~~~~~~~~
 
-That default is built for display, and the two fields differ in what
+The default ``str()`` rendering is built for display, and the two
+fields differ in what
 survives it. The quoted nickname reparses as a nickname; the
 parenthesized maiden name reparses as a *nickname* too, so a
 parse-render-reparse round trip silently loses it:
@@ -807,11 +816,11 @@ names:
 - **Abbreviations with interior periods** are left alone (``E.T.``).
 - **Only the leading run** is read this way: the same word after the
   given name is a middle name.
-- **A word in Han, kana or hangul** is a name word even with a period,
+- **A word carrying a Han, kana or hangul character** is a name word
+  even with a period,
   since those scripts write no abbreviation with one (``"田中. 太郎"``
   has family ``田中.``).
 
-
 .. doctest::
 
     >>> parse("J. Smith").given
@@ -896,19 +905,19 @@ so branching on a kind needs no import:
 Credentials that are also surnames
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The post-nominals that double as ordinary surnames report the same way.
+The post-nominals that double as ordinary surnames report an ambiguity
+the same way.
 Which reading a bare one gets depends on what the writing says:
 
 - **Capitals** in a name written in more than one case lean to the
   credential, even with no words to spare (``Jack MA``).
 - **Any other cased spelling** that is not wholly lowercase leans to
   the surname, even with words to spare (``Jack Ma``, ``John Smith Ma``).
 - **No signal** — all lowercase, or a name written wholly in one
-  case — leaves it to the count: the credential with two or more words
-  before it, the surname otherwise.
+  case — leaves it to the count: the credential with two or more name
+  words before it (a title does not count), the surname otherwise.
 
-Either way the choice is recorded. :ref:`ambiguous-words` has the full
-rules, including how a comma changes them:
+Either way the choice is recorded:
 
 .. doctest::
 
@@ -923,6 +932,9 @@ rules, including how a comma changes them:
     >>> parse("John Smith Ma").family
     'Ma'
 
+:ref:`ambiguous-words` has the full rules, including how a comma
+changes them.
+
 Two ``Policy`` switches extend the same class to words the vocabulary
 does not hold. ``unlisted_dotted_suffixes`` (on by default) reads a
 token of two or more period-separated chunks the same way —
@@ -1022,21 +1034,22 @@ honor, so each view falls back on what it can answer without one:
   capitals wherever the field is the suffix, so ``replace(suffix="mba")``
   repairs to ``MBA`` and ``suffix="vi"`` to ``VI``. A credential
   recognised only by its dotted shape is the exception, since the shape
-  is something the parse records.
-- **Particles** are a fact about the whole part, and no word of a
-  spliced field carries a reading to derive them from, so a family set
-  to ``de la`` stays lowercase where the same words parsed are repaired
-  to ``De La``.
+  is something the parse records. So are particles: whether a particle
+  is acting as one is a fact about the whole part, and no word of a
+  spliced field carries a reading to derive it from, so a family set to
+  ``de la`` stays lowercase where the same words parsed are repaired to
+  ``De La``.
 - :meth:`~nameparser.ParsedName.initials` takes no vocabulary at all,
   so every word of a spliced field contributes an initial.
 - ``family_particles`` and ``family_base`` are properties on the
   parsed name, which holds no vocabulary of its own either:
   ``family_particles`` empties and ``family_base`` takes the whole
   field.
 
-(The v1 :class:`~nameparser.parser.HumanName` facade's ``initials()``
-is also handed a vocabulary and takes the same fallback as
-``capitalized()`` for spliced text; it is not a method of the parsed
+Of the parsed name's own views, ``capitalized()`` is the only one
+handed a vocabulary. (The v1 :class:`~nameparser.parser.HumanName`
+facade's ``initials()`` is handed one too, and likewise asks it whether
+a spliced word is a conjunction; it is not a method of the parsed
 name.)
 
 .. doctest::