Personas prove what goes to relays; the server says what it reads

FEP-521a and FEP-8b32. Every persona has an Ed25519 key of its own (Avatar.SigningKey; migration 014 gives the earlier
ones theirs), named in its actor's assertionMethod as a Multikey, the terms defined in the actor's own context. A
persona's activity going to a relay carries an eddsa-jcs-2022 proof (JSON canonicalised by RFC 8785, Jcs), so what
Activity-Relay forwards reaches Mastodon, which verifies it with its own code. Nothing else carries one: Mitra takes a
proof over the HTTP signature and refuses one by a key it has not read, without reading the actor again. Received: an
actor's own Multikeys are kept, and a forwarded activity whose proof one of them verifies is taken as it came instead of
being read again from its origin.

Discovery: WebFinger for the server's origin links its instance actor (FEP-d556), NodeInfo links it as the application
actor (FEP-2677), and actors name RFC 9421 under implements (FEP-844e).

Checked live: relay 16 (Activity-Relay's forward of alice's post reaches Mastodon), Mitra, GoToSocial and Mastodon
unchanged (165 in all).

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

CLAUDE.md

@@ -84,7 +84,8 @@ PrivaPub/                         ASP.NET Core Web API, net10.0
     Objects/                      Origin, ActivityJson, NoteParser, Addressing, ContentSanitizer
     Moderation/                   DomainBlocks (suspend / silence / reject media)
     Signing/                      HttpSignatures (draft-cavage sign/verify), MessageSignatures (RFC 9421 verify),
-                                  RequestSignature (whichever a request carries)
+                                  RequestSignature (whichever a request carries), IntegrityProofs (FEP-8b32
+                                  eddsa-jcs-2022 by a persona's Ed25519 key, FEP-521a Multikeys), Jcs (RFC 8785)
     Inbox/                        InboxReceiver (verify, queue, 202) → InboxProcessor (job) → Handlers/{Follow,Accept,Reject,
                                   Undo,Create,Update,Delete,Like,Announce}; RemotePosts (build, fetch parents, FetchAncestors);
                                   RemoteReplies (FetchReplies: a thread's `context`, else `replies` two levels down);
@@ -165,7 +166,10 @@ group www-data and reaches the private mongod; `sudo -u www-data` works too.
    (its own `geo` client, a fixed HTTPS host, size-capped, the file checked before it is swapped in).
 2. **Every fetch is signed by the instance actor** (`privapub`), never by a persona; deliveries are signed by the acting
    avatar or group. Both are draft-cavage rsa-sha256 over `(request-target) host date` (+ `digest` on bodies). Inbound,
-   an RFC 9421 signature (`Signature-Input`) is verified too, its target against our public address.
+   an RFC 9421 signature (`Signature-Input`) is verified too, its target against our public address. A persona's own
+   activity going to a relay also carries a FEP-8b32 proof by its Ed25519 key (`Avatar.SigningKey`, one per persona,
+   never shared), and nothing else does: Mitra refuses a proof by a key it has not read. A forwarded activity is taken
+   as it came only when its proof verifies with a Multikey of its actor's.
 3. **A remote document is believed only from its own address.** `RemoteActorService.FetchObject` requires the
    document's `id` to be the URL it was served from (a same-origin alias is followed once). A key is accepted only if
    the actor lists it, its `owner` is the actor and it shares the actor's origin.
@@ -600,8 +604,9 @@ tools/pasture/run.sh down                                            # removes e
   `peers/aoderelay.sh` aode-relay 0.3.129 as `aoderelay.test`):** `appsettings.Pasture.json` names both in
   `Federation:Relays`, so PrivaPub subscribes a minute after it starts. `scenarios/relay.sh` has Mastodon subscribe to
   each in turn, checks that a post of an account nobody here follows reaches the federated timeline (forwarded by one,
-  announced by the other), that alice's public post goes to the relays (and through aode-relay to Mastodon) and nothing
-  less public, and has Mastodon leave again, so the town sees no relayed posts. 15 checks.
+  announced by the other), that alice's public post goes to the relays (and through both to Mastodon: Activity-Relay's
+  forward on its FEP-8b32 proof, after the scenario makes Mastodon read alice's keys anew) and nothing less public, and
+  has Mastodon leave again, so the town sees no relayed posts. 16 checks.
 - **Smithereen (1.0.3):** its image on the shared MySQL (database `smithereen`, its schema from the image's commit),
   with imgproxy and a file server behind Caddy as `smithereen.test` (`/i` and `/s`), trusting the CA through a JDK
   store with it added (`JAVA_TOOL_OPTIONS`). MySQL takes its stored functions only with