Moderate group content from a remote instance

"As a group moderator on a different instance than the group's home, I want to perform moderation actions that are recognized by the group."

When moderators are distributed across instances, we need a flow for remote mods to request actions that the group's home instance executes.

Suggested flow:

1. Group's interactionPolicy (see https://github.com/swicg/groups/issues/26) includes remote moderator in canModerate (or more fine-grained permissions like canCurate):

   "canCurate": {
     "automaticApproval": ["attributedTo"],
     "manualApproval": []
   }
   

   Where attributedTo collection includes remote mod.

2. Remote mod sends action request to group inbox:

3. {
     "type": "Undo",
     "actor": "https://remote.example/users/mod",
     "to: "https://example.org/groups/1",
     "object": {
       "type": "Announce",
       "actor": "https://example.org/groups/1",
       "object": "https://example.org/posts/announced-post-to-hide"
     }
   }
   

   or:

   {
     "type": "Delete",
     "actor": "https://remote.example/users/mod",
     "to: "https://example.org/groups/1",
     "object": {
       "type": "Note",
       "actor": "https://example.org/actors/alice",
       "object": "https://example.org/posts/nested-post-to-hide"
     }
   }
   

4. Group's home instance:

   • Verifies mod has permission
   • Executes the action (removes the Announce)
   • Federates the Undo{Announce} or Delete{Note} to followers

Key insight: The group's outgoing activity IS the authorization. The moderator's instance should not apply this side effect to the group until received from the group's home server.

No implementation files, tests, or entry points are identified. Start by resolving the interactionPolicy dependency in issue #26 and defining how the group inbox verifies remote moderator permissions, executes the action, and federates the resulting activity; done means the flow and its authorization behavior are specified clearly enough to implement.