docs: correct the bot-score claims behind the browser poller

Every doc statement that explained a Cloudflare challenge as a "score"
was wrong. Researched against Cloudflare's own docs on 2026-08-12
(docs/research/cloudflare-bot-scoring-and-poll-cadence.md, 22 primary
pages plus RFC 9309): the 1-99 bot score is Enterprise Bot Management
only, free-plan zones get Bot Fight Mode signature matching and no score
at all, and no per-IP request rate is documented as an input to
challenge issuance. cf_clearance also expires in 30 minutes, so every
cadence at or above 1h re-solves the challenge regardless.

Docs only - no behaviour change. The 6h browser cooldown stays; its
justification is now cost (a serialized single-tab solve costs seconds,
a plain read costs one request), not a risk reduction nothing documents.

- AGENTS.md: the block is per-zone configuration plus request
  fingerprint, not IP reputation; comix.to turning its gate on
  2026-08-12 is the example. Residential egress avoids the
  cloud-hosting-IP signature rather than earning a better score. The UTC
  measurement stands but its mechanism is marked undocumented.
- backend/AGENTS.md: states why the browser cooldown is longer.
- ADR-0003, ADR-0006: dated corrections rather than rewrites. Both
  decisions stand on their other arguments (sweep depth, VPS memory).
- DEPLOY.md: a red smoke run means the Site's settings or this Chrome's
  fingerprint moved, not that "Cloudflare's scoring" did.

docs/adr/0003-series-shared-and-poll-owned.md

@@ -19,8 +19,15 @@ and because the Series row now knows how many Readers hold it, the poll queue is
 absorbs the shortfall. That ordering is only expressible because the split happened.
 
 Raising throughput instead was rejected: sweeping 400 Series hourly needs the stagger
-cut from 20s to ~9s, doubling request rate against sites that already bot-score the
-single VPS IP.
+cut from 20s to ~9s, doubling request rate against sites already fronted by Cloudflare
+from the single VPS IP.
+
+Corrected 2026-08-12: the original wording said those sites "bot-score" the VPS IP.
+They do not — the 1-99 bot score is Enterprise Bot Management only, and no per-IP
+request rate is documented as an input to challenge issuance
+(`docs/research/cloudflare-bot-scoring-and-poll-cadence.md`). The decision stands on
+its first argument, sweep depth versus the 1-hour cooldown; the rate-limit fear was
+never evidenced.
 
 ## Only the Poll writes Series fields
 

docs/adr/0006-browser-on-the-home-machine.md

@@ -23,8 +23,15 @@ requests: the poller's due query joins bookmarks, production held four kagane
 series and no bookmarks on any of them, and with no kagane bookmark the web UI
 never rendered a kagane cover either.
 
-The home machine has 5.9 GiB of swap and a residential egress, which Cloudflare
-scores better than a datacenter IP. Both machines were already on the tailnet.
+The home machine has 5.9 GiB of swap and a residential egress, which avoids the
+cloud-hosting-IP signature Cloudflare's Bot Fight Mode documentedly challenges. Both
+machines were already on the tailnet.
+
+Corrected 2026-08-12: the original wording said Cloudflare "scores" a residential
+egress better than a datacenter IP. There is no score on a free-plan zone; what is
+documented is signature matching, and hosting-provider IP space is one of the
+signatures (`docs/research/cloudflare-bot-scoring-and-poll-cadence.md`). Memory was
+the load-bearing reason regardless.
 
 This move is only safe because covers are persisted (ADR-0005's sibling work,
 issue #43/#45) and the browser is on-demand (ADR-0005). Without stored covers a