A remote thread brings the replies that never reached us

The context of a remote post showed only what PrivaPub happened to hold:
replies from servers nobody here follows were never seen, and only the
ancestors were ever fetched. Now a persona opening a public remote thread
queues FetchReplies for the post and its root, at most once an hour each.

The job reads the thread's own collection first (FEP-7888 `context`, which
Mastodon 4.5+ serves with every reply at any depth; posts or, as FEP-f228
allows, the activities that made them), and otherwise the post's `replies`
(PeerTube's `comments`) and the replies' own, two levels down. At most 5
pages and 100 posts a job, signed by the instance actor, never a persona;
each post is fetched from its own origin and stored through StoreContext,
so only public and unlisted ones are kept.

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

docs/ROADMAP.md

@@ -606,7 +606,12 @@ it, raw where it doesn't.
 
 #### P7 Threads, communities and the social graph
 - **Thread backfill:**
-  - read in order: `contextHistory`, then `context` (paged, with ETag), then `replies`;
+  - read in order: `contextHistory`, then `context` (paged, with ETag), then `replies`. **Done (2026-10-05), but for
+    `contextHistory` and ETags:** a persona opening a public remote thread queues `FetchReplies` for the post and its
+    root, at most hourly each. The job reads the thread's FEP-7888 `context` collection (posts or, as FEP-f228 allows,
+    the activities that made them), else the post's `replies` (PeerTube's `comments`) and theirs, two levels down. It
+    reads at most 5 pages and 100 posts per job, signed by the instance actor, and stores what it lacks through
+    `StoreContext` (public and unlisted only, the author checked against its origin);
   - group by the root post;
   - publish our own `context` and a paged `replies`.
 - **Lemmy, PieFed and Mbin:**