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.

DEPLOY.md

@@ -275,7 +275,8 @@ copy immediately — reinstall on all devices, or they silently stop syncing.
 Kagane and novelfull sit behind a Cloudflare JavaScript challenge no TLS
 fingerprint clears, so the poller reaches them through a real Chrome over CDP.
 That browser does **not** run on the VPS: it held 471 MiB of a 1974 MiB box
-with no swap, and it scores better from a residential IP anyway (ADR-0006). It
+with no swap, and a residential IP avoids the cloud-hosting-IP signature Bot
+Fight Mode challenges anyway (ADR-0006). It
 is its own compose unit, deployed and updated independently of everything
 above.
 
@@ -454,7 +455,8 @@ SMOKE_BROWSER_WS_URL=ws://100.x.y.z:9222 go test -run TestSmokeKagane ./internal
 ```
 
 A red run means "not clearing from this address right now", which is a live
-fact to re-check before it is a defect — Cloudflare's scoring moves. Then, from
+fact to re-check before it is a defect — a Site's Cloudflare settings, and the
+fingerprint this Chrome presents after an update, both move. Then, from
 the web UI, open a bookmarked kagane series and confirm the cover renders. Once
 a cover is stored it is served from Postgres forever after, so the browser being
 asleep, unreachable, or mid-power-outage costs chapter freshness and nothing