Fix fatal error in follower notifications with ActivityPub 7.5.0+

[akirk]

Summary

Fixes #660 — Call to undefined method WP_Post::get() fatal in class-notifications.php when receiving a follow / unfollow from the Fediverse.

ActivityPub 7.5.0 changed the activitypub_followers_post_follow and activitypub_followers_pre_remove_follower hooks to pass a WP_Post for the follower rather than the (now deprecated) Follower model. The Friends notification handlers were still calling Follower methods on it (get(), get_url(), get_name(), …), throwing E_ERROR. The inbox endpoint then returned HTTP 500, so the sending Mastodon server retried the delivery several times — which is what caused the duplicate notification emails and the missing replies in the UI described in the report.

This PR:

• Detects when the follower argument is a WP_Post and resolves it to an Activitypub\Activity\Actor via Remote_Actors::get_actor().
• Computes the avatar via Remote_Actors::get_avatar_url() (the Actor class has no get_icon_url()) and passes it to the email templates as a new icon_url arg.
• Reads the follow start date from the WP_Post's post_date_gmt for the lost-follower duration calculation.
• Keeps backward compatibility with the old Follower model in case the hook is still called the old way.

The outgoing-reply duplication mentioned in the issue is a downstream symptom of the same retry loop and should also be resolved once the inbox stops 500ing.

Test plan

• Have a Mastodon account follow a WordPress user with the Friends + ActivityPub plugins (≥ 7.5.0) installed — confirm a single new-follower email arrives and no fatal is logged.
• Have the Mastodon account reply to a post — confirm the reply arrives once and shows up in the Friends UI / WP comments.
• Have the Mastodon account unfollow — confirm a single lost-follower email arrives with the correct duration.
• Smoke-test outgoing reply from Friends UI — appears once locally, not three times.

Test in WordPress Playground