docs(6205): the remaining services files state the reason, not the instance that taught it

The 1-2 hit tail: access, background, backup, backup_job, canonical_systems,
design_stylesheet, forge_connections, moment_actions, notes, notifications,
placement, planning, platforms, projects, record_batch, recurrence,
report_check, retrieval_review, rule_scope, rule_versions, scheduler,
shape_check, supersession, system_rulings, system_usage, text, trash,
verification, version_pinning.

Also corrected while reading:
- backup.py said restore step 16 fills the System map; step 15 does.
- version_pinning.py pointed at a design doc that is not in the repo.

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

src/scribe/services/background.py

@@ -2,7 +2,7 @@
 
 The event loop holds only a WEAK reference to a task, so a bare
 ``create_task`` with no other holder can be garbage-collected mid-flight — a
-write that never errors and never lands (the #2663 GC footgun). This module is
+write that never errors and never lands. This module is
 the one place that gets the pattern right: strong references in ``_pending``,
 discarded on completion, with failures logged at WARNING instead of vanishing.
 
@@ -36,10 +36,10 @@ async def report_telemetry_failure(subsystem: str, site: str) -> None:
     WARNING to the process log every time; one AppLog error row per process per
     (subsystem, site) so the admin UI shows the outage without host access.
 
-    THIS IS NOT DECORATION. #2663 is the record of a telemetry subsystem running
-    at zero for weeks — every counter reading empty, indistinguishable from
-    "nobody uses this" — because every failure went to ``logger.debug``. A
-    subsystem whose failures are all invisible cannot report its own death.
+    THIS IS NOT DECORATION. A telemetry subsystem whose every failure goes to
+    ``logger.debug`` can run at zero — every counter reading empty,
+    indistinguishable from "nobody uses this". A subsystem whose failures are
+    all invisible cannot report its own death.
 
     The AppLog write is itself guarded: when the database is down it fails too,
     and that is fine. The WARNING already said so, and a canary must never take