feat(500): retire the fixed-question preference arm - completion-report preferences ride the moments

report_preference searched one constant string when a task closed and handed
matches back as update_task's reply_preferences. Milestone 500 step 3 delivers
the reply shapes and the preferences mounted beside them on the moments, so
the arm goes, whole (rule 22):

- services/reply_preferences.py, the REPORT_PREFERENCE RuleArm, its re-scorer
  and corpus entries, and the REPORTPREF constants
- update_task's reply_preferences block and its cue; the docstring now points
  at moment_rules
- the fixed_query field and the fixed_query_never_clears warning: this arm was
  the only one that set it, so the concept and the cannot_decline exemption
  go with it
- the two Settings fields for its floor and budget
- migration 0121 deletes its rows (logs, judgments, rule-usage events, tuning
  history, settings keys), operator-approved 2026-10-09. Without it the
  readout would call the source unregistered and its surfacings would count
  as ambient. The unindexed rule_usage delete is bounded by created_at.

#5496 (step 4 of milestone 500).

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

alembic/versions/0121_retire_report_preference.py

@@ -0,0 +1,59 @@
+"""retire the report_preference arm's rows (milestone 500 step 4)
+
+Revision ID: 0121
+Revises: 0120
+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
+different once the arm is no longer registered:
+
+- `retrieval_logs` / `retrieval_judgments` — a source missing from the
+  registry reads as `unregistered_source`, whose advice is "add it to the
+  registry": the opposite of what happened.
+- `rule_usage_events` — a source missing from `RANKED_SOURCES` reads as
+  ambient, so its surfacings would silently move into the other column of
+  every rule's pull-through.
+- `retrieval_tuning_events` — the tuning history of a surface that no longer
+  exists.
+- `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`
+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.
+
+Not reversible: the arm is not coming back, so neither are its rows.
+"""
+from alembic import op
+
+revision = "0121"
+down_revision = "0120"
+branch_labels = None
+depends_on = None
+
+SOURCE = "report_preference"
+# A safe floor under the arm's first row (it shipped after 2026-09-14).
+ARM_BORN = "2026-09-01"
+
+
+def upgrade() -> None:
+    op.execute(f"DELETE FROM retrieval_logs WHERE source = '{SOURCE}'")
+    op.execute(f"DELETE FROM retrieval_judgments WHERE source = '{SOURCE}'")
+    op.execute(
+        f"DELETE FROM rule_usage_events WHERE created_at >= '{ARM_BORN}' "
+        f"AND source = '{SOURCE}'"
+    )
+    op.execute(f"DELETE FROM retrieval_tuning_events WHERE surface = '{SOURCE}'")
+    op.execute(
+        "DELETE FROM settings WHERE key IN "
+        "('kb_reportpref_threshold', 'kb_reportpref_top_k')"
+    )
+
+
+def downgrade() -> None:
+    pass