Everything on, phase 2 completed: SecureMode on in production, checked by the deploy

Owner decision 2026-10-04: SecureMode on once the pasture passes with it.

- Both clean pasture passes were run over all six peers:
  - normally: 246 passed, 0 failed;
  - with Federation__SecureMode=true: every federation check passed. The only failures were four checks expecting an
    unsigned GET to get 404 or 410 where SecureMode answers 401. Those checks now go through `unserved` and
    `gone_unsigned` (lib/interop.sh), which expect 401 when SecureMode is on.
- Circle posts now reach their member on GoToSocial and Mastodon, and survive Mastodon's signed refetch, as does a
  followers-only post. The GoToSocial expected failure is gone.
- appsettings.Production.json turns SecureMode on.
- The deploy now checks that an unsigned GET of @thepra answers 401 and that a browser is redirected. It reads
  @thepra's discoverability through the Mastodon API, since the actor is no longer readable unsigned.
- docs/INTEROP.md (Mastodon, GoToSocial), CLAUDE.md and ROADMAP updated.

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

docs/INTEROP.md

@@ -169,15 +169,19 @@ Priorities, used throughout:
 Findings:
 - **Mastodon 4.7 names its actors by number**: `https://mastodon.test/ap/users/<id>`, inbox `…/ap/users/<id>/inbox`. Nothing here may assume
   `/users/<name>`.
-- **It drops circle posts** (expected failure in the scenario).
+- **It dropped circle posts** until each member's copy named that member (owner decision 2026-10-04, v1.19.0).
   - A post addressed only to `[circle, circle/flock]` parses as `direct` there, and Mastodon keeps a `direct` post
     only if it names a local account or arrived in a known account's inbox (`Create#addresses_local_accounts?`).
   - But `ActivityPub::InboxesController#account_required?` looks only at `params[:account_username]`. A delivery to
     the numeric `/ap/users/:account_id/inbox` it now advertises therefore reaches the worker with no recipient and
     is rejected.
   - DMs are unaffected because they name the recipient.
-  - Fixing it on our side means naming the member (or that server's members) in each copy's `cc`, which changes what a
-    circle reveals: **owner decision pending**. Reporting it upstream is the other half.
+  - Each member's copy now names that member in `cc` and mentions them silently, so Mastodon keeps it, and its signed
+    refetch (`ActivityPub::FetchRemoteStatusService`, by its instance actor) gets the post back naming the members on
+    that server. The same holds for a followers-only post's refetch, which used to answer 404, and a 404 on refetch
+    makes Mastodon delete its copy. Reporting the numeric-inbox recipient loss upstream is still worth doing.
+- **With SecureMode on** (all six peers, 2026-10-04) every federation check passes: Mastodon, GoToSocial, Misskey,
+  Sharkey, Akkoma and Lemmy all sign their fetches, and fetch our instance actor's key unsigned first.
 - Inbound `Block` from Mastodon is not enforced yet (P7).
 
 ### GoToSocial: 0.22.1 (2026-07-20)
@@ -233,7 +237,10 @@ Findings:
 
 **Pasture evidence (2026-10-03, GoToSocial 0.22.1, `tools/pasture/scenarios/gts.sh`):** 37 checks pass, three runs in a
 row. That is the original 33 plus four on statistics: described as gotosocial, inbound and outbound traffic counted,
-no account named.
+no account named. Since 2026-10-04 (v1.19.0) circle posts reach a GoToSocial member too. GoToSocial files a post for
+neither the public nor the author's followers as a direct message, like our DMs, and shows it only to the accounts it
+mentions. Being in `cc` stored it but left it invisible, so each member's copy also mentions that member silently.
+Such posts are then found in the member's conversations, never by a search on their URI.
 
 ### Misskey family: Misskey 2026.10.0, Sharkey 2025.4.7, Iceshrimp.NET 2026.1.2-beta, CherryPick 4.17