GoToSocial's interaction policies are honoured

A remote post's canReply, canLike and canAnnounce (with the older always and approvalRequired) are kept beside
canQuote and judged for each persona: let in at once when the rule names the public, the persona, the author's
followers while it follows the author, or the accounts the author follows while the author follows it; asked first
when only the manual list names it; refused (422) otherwise. Asked first, a ReplyRequest, LikeRequest or
AnnounceRequest with the interaction as its instrument goes to the author alone, and the interaction waits
(privapub.approval: pending). The author's Accept brings an authorization, verified on the author's origin as naming the
interaction and the post; the reply then goes out with replyAuthorization, the boost with announceAuthorization, the
like with likeAuthorization. A Reject leaves the reply ours alone and takes a like or a boost back. As a third party, a
reply a policy does not let in at once is kept only with an authorization that verifies. Clients see the rules as
GoToSocial's interaction_policy.

Checked live against GoToSocial 0.22.1: the scenario's nine new checks pass (64 in all), a reply and a like approved
through its interaction requests and a boost refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw

CLAUDE.md

@@ -98,7 +98,8 @@ PrivaPub/                         ASP.NET Core Web API, net10.0
     Privacy/                      VisibilityPolicy (IsPublic expression, CanSee)
     Relationships/                RelationshipService (blocks, mutes, account domain blocks; Hidden), ReportService
     Media/                        MediaService (libvips, ffmpeg remux, blurhash), MediaProxy, MediaJanitor
-  Domain/Statuses/                StatusService: publish, edit, remove, favourite, reblog, for a persona (both client APIs use it)
+  Domain/Statuses/                StatusService: publish, edit, remove, favourite, reblog, for a persona (both client APIs use it);
+                                  InteractionApprovals: GoToSocial's canReply/canLike/canAnnounce, judged, asked and answered
   Api/Mastodon/
     Auth/                         OpenIddict setup (keys in Mongo), MastodonScopes, TokenController, OAuthPruner
     Infrastructure/               MastodonController (avatar context, scopes, errors, Link), MastodonParams, MastodonJson, Page
@@ -473,9 +474,10 @@ tools/pasture/run.sh down                                            # removes e
     delete is checked as a 404 on `/api/v1/statuses/{id}`.
   - It creates its accounts locked, so the scenario approves alice's request through `/api/v1/follow_requests`, which
     also checks our pending (`requested`) state and the manual Accept.
-  - 55 checks: discovery and follows both ways; posts and CW; a reply and its notification; likes and boosts both
+  - 64 checks: discovery and follows both ways; posts and CW; a reply and its notification; likes and boosts both
     ways; DMs both ways and off public timelines; polls both ways; quote policy; link cards; edits and deletes both
-    ways; communities and circles; locked personas; unfollow; block and unblock; statistics.
+    ways; communities and circles; locked personas; interaction policies (a reply and a like asked for and approved
+    through `/api/v1/interaction_requests`, a boost refused); unfollow; block and unblock; statistics.
   - It files a circle post as a direct message and shows it only to the accounts it mentions, so like a DM it is
     checked in the member's `/api/v1/conversations`, never by URI.
 - **Mastodon (4.7.3):** web and sidekiq on the shared Postgres and Redis, `ALLOWED_PRIVATE_ADDRESSES` for the network.