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

docs/INTEROP.md

@@ -235,8 +235,8 @@ Findings:
 
 | Gap | P | Client surface |
 |---|---|---|
-| Store remote `interactionPolicy` (with GoToSocial's defaults); disable or mark actions | P1 | GoToSocial-style `Status.interaction_policy` |
-| Send `ReplyRequest`/`LikeRequest` where approval is needed; handle `Accept{result}`/`Reject`; attach the authorization | P1 | own: pending/approved/rejected on our own reply |
+| ~~Store remote `interactionPolicy` (with GoToSocial's defaults); disable or mark actions~~ done 2026-10-05 | P1 | GoToSocial-style `Status.interaction_policy` |
+| ~~Send `ReplyRequest`/`LikeRequest` where approval is needed; handle `Accept{result}`/`Reject`; attach the authorization~~ done 2026-10-05 (`InteractionApprovals`), `AnnounceRequest` too | P1 | `privapub.approval`: pending/rejected on our own reply or boost |
 | Honour 503 with `Retry-After` in delivery and in the proxy | P1 | — |
 | Respect `hides*FromUnauthedWeb` on our public pages; emit it for personas (it suits the privacy design) | P2 | — |
 | Measure media size when proxying | P2 | `MediaAttachment.meta` |
@@ -244,8 +244,11 @@ Findings:
 
 **Pasture evidence (2026-10-03, GoToSocial 0.22.1, `tools/pasture/scenarios/gts.sh`):** 37 checks pass, three runs in a
 row. That is the original 33 plus four on statistics: described as gotosocial, inbound and outbound traffic counted,
-no account named. On 2026-10-05 the scenario runs 55 checks, all passing, and can be run again on the same pasture (the
-locked persona loses its follower first). Since 2026-10-04 (v1.19.0) circle posts reach a GoToSocial member too. GoToSocial files a post for
+no account named. On 2026-10-05 the scenario runs 64 checks, all passing, and can be run again on the same pasture (the
+locked persona loses its follower first). Nine of them are interaction policies: gtsuser's post asks before anyone but
+its author replies or likes and lets nobody else boost it; PrivaPub shows the policy, refuses the boost, sends alice's
+reply and like as a `ReplyRequest` and a `LikeRequest`, and once gtsuser approves them the reply threads under the
+post and the like counts. Since 2026-10-04 (v1.19.0) circle posts reach a GoToSocial member too. GoToSocial files a post for
 neither the public nor the author's followers as a direct message, like our DMs, and shows it only to the accounts it
 mentions. Being in `cc` stored it but left it invisible, so each member's copy also mentions that member silently.
 Such posts are then found in the member's conversations, never by a search on their URI.