docs(6209): snippets, rule embeddings, notes, ledger ageing and references, routes, reporting, handshake, lesson kind, request deadlines, contract-around-change, family models

Twelve more test files drop issue, milestone, rule, note, lesson and
snippet numbers and the dated or one-project figures that recorded how
each property was found; the docstrings state the property and why it
holds. The contract-around-the-change guard keeps the dict-key example as
the failure a signature-watcher misses.

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

tests/test_integration_lesson_kind.py

@@ -1,17 +1,17 @@
-"""A lesson is a row the database actually accepts (milestone 385 step 2).
+"""A lesson is a row the database actually accepts.
 
 WHY THIS IS THE REAL GUARD, AND WHY IT IS HERE
 
-The step asked for "a guard that the CHECK actually accepts `lesson` and
-rejects a typo", citing #3128 — a `spike` kind that could not be written on an
-instance predating its migration. That failure mode belongs to `task_kind`,
+The obvious ask is a guard that a CHECK accepts `lesson` and rejects a typo —
+the failure where a new kind cannot be written on an instance predating its
+migration. That failure mode belongs to `task_kind`,
 which IS gated (`notes_task_kind_check`, migrations 0056 and 0065).
 `note_type` is not gated at all: migration 0036 added it as plain Text with a
 server default and nothing has constrained it since.
 
 So there is no whitelist to expand and no rejection to assert. Writing the
-guard as "the constraint admits lesson" would have pinned a constraint that
-does not exist; writing it as "no constraint exists" would pin today's schema
+guard as "the constraint admits lesson" would pin a constraint that does not
+exist; writing it as "no constraint exists" would pin today's schema
 rather than the behaviour that matters, and would go red on a change that is
 perfectly fine.
 
@@ -19,7 +19,7 @@ Asserting the WRITE covers both worlds. It passes today, it keeps passing if a
 CHECK is added that admits `lesson`, and it goes red the day one is added that
 does not — which is the only outcome anyone needs to be told about.
 
-The second test is the cell #3163 asks to be left empty on purpose: a lesson
+The second test is the cell left empty on purpose: a lesson
 must not be a task. `is_task` is a read-only property over `status`, so this
 cannot be asserted by setting a flag — it has to be observed on a real row.
 """
@@ -83,13 +83,13 @@ async def test_a_lesson_is_a_row_the_database_accepts(owner_id):
     # and the readable body — because the vector is built from the text and
     # the queries are built from the mirror.
     assert lessons_svc.lesson_trigger(stored) == TRIGGER
-    # The subject alone (milestone 427): the trigger is in `data` and the body.
+    # The subject alone: the trigger is in `data` and the body.
     assert stored.title == SUBJECT
     assert "**When to apply:**" in (stored.body or "")
 
 
 async def test_a_lesson_is_not_a_task(owner_id):
-    """#3163's cell left empty on purpose.
+    """The cell left empty on purpose.
 
     `is_task` is `status is not None` and is read-only, so this is only
     observable on a stored row. A lesson that arrived with a status would join