docs: correct 3cff97d — the 'ratelimited' bug was not real

I claimed done_ids() was binning rate-limited tasks forever. It wasn't:
/task-completed has always refused to persist 'ratelimited' and 'requeue'
rows (they stay PENDING by design), so such an id can never reach
results.jsonl. Verified against the copy that was actually running.

The done_ids() guard stays as defence in depth against a hand-appended row,
but its comment no longer claims to fix a bug that didn't exist. The real
bug in that commit — no circuit breaker on a failure streak — stands, as
does the actual root cause in 82d5ff4 (promptEchoed matched a 60-char prefix).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

local_server_example.py

@@ -84,12 +84,12 @@ def load_queue():
 def done_ids():
     """Ids that must NOT be handed out again.
 
-    'ratelimited' is deliberately absent. handleRateLimit() writes that status meaning
-    "report the task back as pending" — no gen ran, the abuse flag just froze us mid-task.
-    Counting it as done silently binned the task forever, contradicting its own comment.
-
     'failed' IS counted: a timeout may have burned credits invisibly, so nothing is retried
     automatically. To re-run a failed task, delete its line from results.jsonl (requeue.py).
+
+    'ratelimited'/'requeue' are skipped belt-and-braces: /task-completed already refuses to
+    persist those rows (they stay PENDING by design), so they can't reach this file. This is
+    defence in depth against someone appending a row by hand — not a bug fix.
     """
     ids = set()
     if os.path.exists(RESULTS_FILE):