docs: use fictitious data and make the phone reference reachable

[lhagenWP]

Why

Two things that shipped in the phone lookup docs need correcting.

The examples were real. They were a response captured from a running
service: an identifiable business, its carrier, its number. They are published
now.

The reference page has no way in. /references/phone-v2/get_phone_by_number_v2
exists and renders, but the References rail lists its directories by hand and
phone-v2 was not among them. A reader reaches the page only by typing the
URL. Getting Started mentions a phone number only as something person search
accepts as a parameter.

What Changed

Examples in the guide and the changelog are fictitious: John Smith on
(206) 555-0142, placeholder identifiers, matching what the other guides use.
Phone numbers come from the 555-01xx range reserved for documentation, and a
callout on the guide says the values are invented so nobody mistakes them for
live data.

The business example stays, because approximate_locations needs a business to
illustrate and that is the endpoint's new capability — but the business is
invented too.

phone-v2 is added to the References rail, after person-v2. Getting Started
gains a Phone Lookup card beside Person Search and a mention in Next Steps.

The reference pages are regenerated from the published spec, as a second
commit. The service stopped publishing its handler docstrings, so the spec no
longer carries numpydoc sections or the reStructuredText markup this site
renders as literal backticks. Descriptions only, on five pages: the phone
lookup loses a Parameters and Returns block naming Python arguments and
internal types; person, property and deed-event search lose Raises blocks
naming exception classes; the property detail page's code spans render as code.

Context

The rail file is hand-maintained; the generator writes each directory's own
meta.json but not the parent list, which is why generating the page did not
make it reachable. Worth knowing for the next endpoint that gets added.

The regeneration had to wait for the service change to reach production, since
the generator reads the live spec at api.whitepages.com/openapi.json. I
confirmed the deployed image is that change's merge commit and that the live
spec has no remaining leaked sections before regenerating.