Resolve actors via the proxyUrl endpoint instead of the ap_actor cache

[pfefferle]

Goal

When the app needs a remote actor object, resolve it through the actor's proxyUrl endpoint — the spec-defined C2S way to fetch a remote AP object via the server — instead of reading the local ap_actor cache.

Why

A real C2S client resolves remote objects through endpoints.proxyUrl, not a server-side post-type cache: fresher data, no direct cross-origin fetch, and consistent with the event-sourcing client (#3427/514). The endpoint already exists.

Current state (verified in code)

• The app reads actors from the ap_actor post type (Remote_Actors) via @wordpress/core-data in src/app/hooks/use-followers.ts; actor-profile fields (actor_info, webfinger, avatar…) come from that cached row.
• The proxy endpoint exists: includes/rest/class-proxy-controller.php — POST /activitypub/1.0/proxy (+ /proxy/stream), permission_callback = verify_authentication (OAuth). Advertised as endpoints.proxyUrl / proxyEventStream in includes/model/class-user.php and class-blog.php.

Scope

• Add a proxy-backed actor resolver in the C2S client/binding: given an actor IRI, POST /proxy with the id and feed the returned actor object into the read model (per Build the reusable C2S event-sourcing client core (store + reducer + controller) #3427).
• Route the app's actor-object reads through it, replacing the direct ap_actor core-data read for profile data.

Open question (confirm scope)

• The follower/following relationship (who follows you) is inherently local — only the actor object/profile resolution should move to proxyUrl; the membership/list source likely stays ap_actor. Confirm whether this issue covers only profile resolution or also the list source.

Auth

• /proxy is OAuth-authenticated (verify_authentication), so it shares the admin-token concern tracked in WordPress binding: replay the outbox event log into an Activities view #3428.

Relates to #3427 (client core) / #3428 (binding).