Pasture: WordPress pinned with its updates off, Mbin's worker restarting, threads checking our own deliveries

A full sweep found three peers silent. WordPress had updated itself to 7.1.2 from WP-Cron, and the new CA bundle dropped
Caddy's root: it now runs the 7.1.2 image with automatic updates off. Mbin's messenger worker had died when the shared
Postgres restarted under it: it now consumes again whenever it stops. Friendica sat in a quarantine left by the old
breaker. The threads scenario checks that PrivaPub never sends carol's reply to Mastodon, since a relay Mastodon has just
left (the relay scenario's) may still pass it on. With these, every scenario passes but the crawler's, which needs it
switched on.

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

CLAUDE.md

@@ -548,7 +548,8 @@ tools/pasture/run.sh down                                            # removes e
   communities both ways, threads with titles, comments, votes up and down both ways, a community poll and alice's vote,
   private messages both ways, a moderator's lock, unlock and removal, the unfollow, statistics.
 - **Mbin (1.10.1):** its own image (FrankenPHP serving plain HTTP behind Caddy, `SERVER_NAME=:80`) and a messenger
-  worker, on the shared Postgres and Redis (db 12) with a RabbitMQ of its own (its transports carry AMQP options; it
+  worker (`mbin_worker`, consuming again whenever it stops: once, the shared Postgres restarted under it and Mbin sent
+  nothing for a day), on the shared Postgres and Redis (db 12) with a RabbitMQ of its own (its transports carry AMQP options; it
   runs as its own user on its own volume, or it cannot read the `.erlang.cookie` it wrote as root). The pasture's bundle
   is mounted over the system one; its API's rate limits (two threads every six minutes) are raised by a copy of its
   `rate_limiter.yaml`. Its admin mbuser is made by its console; `peers/mbin_token.py` gets mbuser's OAuth token through
@@ -681,11 +682,13 @@ tools/pasture/run.sh down                                            # removes e
   clients from a million (Passport refuses a token whose user id equals its client's id), and imports its cities.
   Tokens are personal access tokens made through tinker (`App\Models\User`). Every top-level post needs a picture.
   `scenarios/pixelfed.sh`, 26 checks; the town's driver and `specs/pixelfed-pair.json`.
-- **WordPress (6, ActivityPub plugin 9.3.1):** the official image on a shared MySQL 8.4 (`shared_mysql_up`, ready only
-  when it answers over TCP: its first start runs a server without networking), installed and configured by wp-cli,
+- **WordPress (7.1.2, ActivityPub plugin 9.3.1):** the official image on a shared MySQL 8.4 (`shared_mysql_up`, ready
+  only when it answers over TCP: its first start runs a server without networking), installed and configured by wp-cli,
   its CA bundle (`wp-includes/certificates/ca-bundle.crt`) given Caddy's root, and WP-Cron run every five seconds by a
-  sidecar (`DISABLE_WP_CRON`), since the plugin federates from it. Authors are actors; the REST API takes application
-  passwords. `scenarios/wordpress.sh`, 17 checks.
+  sidecar (`DISABLE_WP_CRON`), since the plugin federates from it. Its automatic updates are off
+  (`AUTOMATIC_UPDATER_DISABLED`): the sidecar ran one (6 to 7.1.2) whose new CA bundle dropped Caddy's root, and
+  WordPress reached nobody after it. Authors are actors; the REST API takes application passwords.
+  `scenarios/wordpress.sh`, 17 checks.
 - **Friendica (2026.05):** the official image on the shared MySQL (database friendica) and Redis (db 7, for its cache,
   locks and sessions), installed by its autoinstall, with the image's worker daemon (`cron.sh`) as a sidecar sharing
   its files. `friendica_settle` repairs what the install leaves: it names the system user (uid 0), or Friendica never