P5 done: a key we cannot fetch for now gets 503, and follow/like/block ids stay private on purpose

- When a sender's key cannot be fetched because its server timed out or answered 5xx, the inbox answers 503 with
  Retry-After: 300 instead of 401, so Mastodon 4.7 retries rather than switching to RFC 9421 signatures we do not
  verify yet. The fetcher's failure cache now remembers whether a failure was temporary.
- Follow, Like, Block, Accept, Reject and Undo ids are deliberately not dereferenceable: serving them would publish
  who follows, likes and blocks whom. They are always sent with their object embedded.

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

FEDERATION.md

@@ -132,6 +132,11 @@ Posts with a location (shown to nearby users of this server) never leave the ser
 - **Fetching.** All fetches are signed by the instance actor. They go only to public addresses, follow at most three
   redirects and read at most 1 MB.
 - **HTML.** Received HTML is sanitised to Mastodon's allowlist.
+- **Keys we cannot fetch for now.** When a sender's key cannot be fetched because its server timed out or answered
+  5xx, the inbox answers 503 with `Retry-After: 300` rather than 401.
+- **Activity ids.** `Create` and `Announce` ids dereference. `Follow`, `Like`, `Block` and the `Accept`, `Reject` and
+  `Undo` that answer them do not, because serving them would reveal who follows, likes and blocks whom; they are always
+  sent with their object embedded.
 - **Delivery.** Failed deliveries are retried with Mastodon's backoff (16 attempts). A host that keeps failing is paused,
   starting at an hour and growing to a week.