docs: design the telemetry schema gate and the retention boundary

Both open issues ask the same question from opposite sides: how much
power the library holds over a downstream database. #13 wants the
structural writes back, #12 wants the data retention back. The two
designs share one boundary -- the library does SELECT and INSERT plus
an optional CREATE, and everything that alters structure or deletes
rows belongs to the downstream, with the library obliged to print the
exact SQL they need to run.

Two findings shape #13 beyond what the issue argues. The precedents it
cites (Hangfire's lock queue, Prefect's multi-instance race, Alembic's
audit trail) all live on a shared production Postgres, while the SQLite
side is a local file with no DBA and no migration tool, so the defaults
split by backend rather than uniformly. And turning ALTER off only
works together with trimming the INSERT to the columns that exist:
without it a stale table drops every row instead of two columns, which
breaks the telemetry rule harder than the automatic ALTER ever did.

For #12 only the body cap touches library code; retention and access
control land in the README, because the sdist carries src and the
README alone -- a template that lives in the wiki is one a downstream
pip install cannot reach.

research-wiki/graph/edges.json

@@ -165,6 +165,16 @@
       "id": "plan:issue11-caller-dimensions",
       "label": "调用方自定义维度实现计划(issue #11)",
       "type": "plan"
+    },
+    {
+      "id": "design:issue13-schema-mode",
+      "label": "issue #13: 遥测 schema 自动 ALTER 降级为按后端不对称的显式档位",
+      "type": "design"
+    },
+    {
+      "id": "design:issue12-telemetry-retention",
+      "label": "issue #12: 遥测表的正文体量、保留期与访问控制",
+      "type": "design"
     }
   ],
   "links": [