docs(6207): migrations 0101, 0105, 0106, 0108, 0120, 0121 drop citations and the operator quote

0121 keeps the ARM_BORN date beside the constant it justifies.

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

alembic/versions/0121_retire_report_preference.py

@@ -1,4 +1,4 @@
-"""retire the report_preference arm's rows (milestone 500 step 4)
+"""retire the report_preference arm's rows
 
 Revision ID: 0121
 Revises: 0120
@@ -6,8 +6,8 @@ Create Date: 2026-10-09
 
 The fixed-question arm that searched for completion-report preferences when a
 task closed is gone: the reply shapes and the preferences mounted beside them
-now arrive on the moments (milestone 500 step 3). Its rows go with it (rule
-22 — no legacy to preserve), because each one would otherwise mean something
+now arrive on the moments. Its rows go with it (there is no legacy to
+preserve), because each one would otherwise mean something
 different once the arm is no longer registered:
 
 - `retrieval_logs` / `retrieval_judgments` — a source missing from the
@@ -21,11 +21,10 @@ different once the arm is no longer registered:
 - `settings` — the arm's floor and budget keys, which nothing reads.
 
 COST IS BOUNDED BY AN INDEX, NOT BY THE TABLE. A migration runs at boot
-against the live tables, which CI never has (lesson #5221). `retrieval_logs`
+against the live tables, which CI never has. `retrieval_logs`
 and `retrieval_judgments` are indexed on `source`. `rule_usage_events` is not,
-so its delete is also bounded by `created_at` (indexed): the arm shipped with
-milestone 409 step 4, decided 2026-09-14, so no row of it predates
-`ARM_BORN`, and the scan covers weeks rather than the table's whole history.
+so its delete is also bounded by `created_at` (indexed): no row of the arm
+predates `ARM_BORN`, and the scan covers weeks rather than the table's whole history.
 
 Not reversible: the arm is not coming back, so neither are its rows.
 """