FEP-8fcf rests for two weeks after a restore

What a restore lost of either side is not the other server's to mend: for RestoreRecord.FollowersGrace (14 days)
deliveries carry no Collection-Synchronization header, and a follow only the remote remembers is adopted rather than
undone. Without a restore nothing changes; the interop sweep (gts, mastodon, misskey, sharkey, akkoma, pixelfed,
smithereen, followsync, pins, moves) passed, Smithereen's poll check on a second run.

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

CLAUDE.md

@@ -525,7 +525,9 @@ group www-data and reaches the private mongod; `sudo -u www-data` works too.
   Each attempt redoes everything. Refused before anything changed, it is abandoned and recorded, and the server boots as
   it was; failed midway, the process exits 1 and the next start tries again; after 3 failures it exits 75, which the
   unit's `RestartPreventExitStatus` leaves down for someone to look. While `restore.json` exists, commands exit 75 (but
-  `admin restore --status`) and the deploy refuses to run.
+  `admin restore --status`) and the deploy refuses to run. For `RestoreRecord.FollowersGrace` (14 days) after a restore,
+  FEP-8fcf rests: no `Collection-Synchronization` header goes out, and a follow only the remote remembers is adopted,
+  not undone.
 - **The administrator's page** (`BackupController`, `/clientapi/admin/backups`; owner decision 2026-10-07, which approved
   these endpoints in production): the list (with what runs, the restore waiting, the last restore's report, logins
   deleted since each backup), back up now (202; the page polls), delete, and: