Custom handle changes don't propagate to other Ghost instances

Summary

When an account sets a custom handle, that handle appears to be visible only on the instance that hosts it. Other Ghost instances keep displaying the handle derived from the actor's hostname and never pick up the change — not on first contact, and not after the remote actor sends an Update.

This isn't visible on Ghost Pro, where the accounts involved are all on the same instance. It shows up as soon as two Ghost instances are involved.

Reproduction

@john@john.onolan.org changed his handle to @john@onolan.org.

The actor document is unchanged by the switch — same id, same preferredUsername, no movedTo:

curl -sL -H 'Accept: application/activity+json' \
  https://john.onolan.org/.ghost/activitypub/users/index
# id                = https://john.onolan.org/.ghost/activitypub/users/index
# preferredUsername = john

The new handle exists only in the WebFinger subject:

curl -sL 'https://john.onolan.org/.well-known/webfinger?resource=acct:john@john.onolan.org'
# {"subject":"acct:john@onolan.org", ...}

Expected: a remote Ghost instance displays @john@onolan.org.
Actual: it displays @john@john.onolan.org, indefinitely.

Other implementations handle this

Three unrelated Mastodon instances resolved the change correctly, and dropped the old form entirely:

mastodon.social   acct=john@onolan.org      john@john.onolan.org -> Record not found
mstdn.social      acct=john@onolan.org      john@john.onolan.org -> Record not found
fosstodon.org     acct=john@onolan.org      john@john.onolan.org -> Record not found

curl -s 'https://mastodon.social/api/v1/accounts/lookup?acct=john@onolan.org'

So the information is on the wire in a standard field and is discoverable by any server that reads it. It just isn't pushed — there's no activity to wait for.

Environment

• ghcr.io/tryghost/activitypub:edge, image sha-eeacfc7 (eeacfc75740c803fdfdc94a9f7c3477dc28fbb6b, built 2026-08-19)
• Self-hosted, MySQL, Pub/Sub MQ
• Also checked against main at eb5b7fe; the commits between the two are dependency bumps only

Start by querying the WebFinger and actor-document URLs in the reproduction, then trace how a remote instance handles the WebFinger subject and incoming Update. Compare lookups for the new and old handles across two Ghost instances; done means the new handle is displayed remotely and the hostname-derived form no longer persists.