Only publish blocks that are still in force

ipblock_registered and domain_blocked only ever meant "we posted this
block once" — they said nothing about whether it still exists. When the
API went live it was publishing 24 /32 ranges that had been removed by
hand on 2026-07-21, so ~17% of the IP list didn't block anything. That's
a bad thing to hand another admin an importer for.

app/reconcile_blocks.py fetches Mastodon's live Admin::IpBlock and
Admin::EmailDomainBlock lists and maintains a new block_active column on
both tables: off for rows whose block is gone or whose expires_at has
elapsed, back on for any that reappear. The API serves only active rows.
Re-registering a block reactivates its row, so a range the bot blocks
again after a manual cleanup comes back on its own.

A failed fetch changes nothing — not a 403 from a missing scope, not
Mastodon being down, not a half-failure where one list answers and the
other doesn't. An outage must never be read as "every block was
removed"; the list degrades to over-reporting rather than emptying
itself, and there's a test for each of those paths.

Needs admin:read:ip_blocks + admin:read:email_domain_blocks, added to
the live token in place (scopes updated on the existing Doorkeeper
token, matched by digest) rather than by minting and rotating, so the
token value is unchanged and .env needed no edit.

.env.example

@@ -241,6 +241,10 @@ SUSPICIOUS_COMBINED_DRY_RUN=true
 # paths 404 as if they didn't exist. yttrx.com sets this to true.
 BLOCKS_API_ENABLED=false
 
+# The list is kept honest by app/reconcile_blocks.py (cron, hourly), which
+# drops entries whose block no longer exists in Mastodon. That needs
+# admin:read:ip_blocks + admin:read:email_domain_blocks on ABUSE_BOT_TOKEN.
+
 # Hard ceiling on entries per response, whatever ?limit asks for — the
 # endpoint is unauthenticated, so response size can't be left to the caller.
 BLOCKS_API_MAX_ITEMS=5000