1.32.1

A fix to the preview screen that shipped in 1.32.0, and the document that says
how to use it.

The preview could mislabel a site's own field

DPT_RB_Fields::compat() records names without the targets they landed on —
deliberately, so a second definition of a key cannot report the same alias
twice. The preview marked every field row whose name appeared in that list,
which is not the same question. A site that defines reading_time on pages,
while the compatibility layer adds reading_time to posts, saw its own field
labelled as somebody else's — on the screen used to decide whether to
deactivate a working plugin.

The names are now listed on their own instead, and the list says what it
actually holds: names the replaced plugin published, and jet_-prefixed
aliases invented when a field's own name is one a core REST property already
owns. Only the first kind is API surface anything outside the site can depend
on.

docs/rest-bridge-deployment.md

The order to deploy REST Bridge in, which matters more than it looks:

• Enable the module before deactivating digitizer-api-extensions. The
  module ships disabled and stands down while the old plugin is present, so
  that order leaves no gap; the reverse leaves the site with neither, and
  requests arriving in that window get 404s or fields missing.
• Compare fields, not routes. faq/bulk is dropped by design and
  faq/info is replaced by /info, so a like-for-like route comparison lands
  every deployment in the "exposes less — stop" case on a difference that was
  intended.
• GET /wp-json/digitizer/v1/info needs authenticating; it requires
  edit_posts and answers 401 anonymously, which at the verification step
  looks exactly like a deployment that failed.

Seven review findings went into this, six of them in the instructions rather
than the code.