docs(W24): 交付件口径纠错 —— D2.4 自相矛盾 / D2.5 过期块数 / D4.8 墓碑行误标 / D2.6 补 W24 状态

复核时发现四处「交付件里的事实错误」，逐条修：

- D2.4 §AC-04/AC-05 段：正文写「本仓库 _chunks.jsonl 当前 617 块全部为 public」，
  与本文档自己的 v1.6/v1.8 版本行（public 730 / registered 25）自相矛盾。
  改为标「设计当时」+ 补 v1.8 现状（755 块），并写明 AC-04/AC-05 现已可证伪、
  不再需要「造一条测试块」（双向验证已于 2026-09-18 实测通过）。

- D2.5 演示脚本：「族判定（family_id 628 块全覆盖）」→ 755 块（W24 复测）。
  这是答辩当天要照着念的稿子，块数必须与实库一致。

- D4.8 §9.2：把「新集合条数 basic 105 / product 398 / faq 300 / policy 576」
  当成真实条数引用 —— 那组数字是 upsert 留下的墓碑行被计入
  get_collection_stats().row_count 的结果（同 D2.1 v6.9：298/576/382 = 存活行
  149/288/191 的两倍）。已补口径更正段，写明本轮复测的存活行数
  251/154/288/62 = 755，并定下「引用块数一律用 _chunks.jsonl，不用 row_count」。

- D2.6 答辩报告：补一条 2026-09-21 W24 状态更新 —— ① docs/43 场内基金手册已入库
  （20 只场内基金，702 → 755 块），「问在库产品却答另一只」的根因已根除；
  ② 出口经 E2c-my 细分后共六个（E1/E2/E2c-my/E3/E4/E5），转人工只在 E5c。

已复核：Milvus 四集合存活行数与 knowledge/_chunks.jsonl 逐集合一致（288/251/154/62 = 755），
无墓碑行残留；recalls_customer_memory 仍为 False，与 D2.7 记载一致。
D2.4 HTML 结构自检通过（table/tr/td 标签配平）。

docs/evidence/knowledge-collections.json

@@ -2,7 +2,7 @@
   "collections": [
     {
       "collection": "fin_basic_collection",
-      "row_count": 46,
+      "row_count": 62,
       "field_names": [
         "doc_id",
         "title",
@@ -120,7 +120,7 @@
     },
     {
       "collection": "fin_faq_collection",
-      "row_count": 150,
+      "row_count": 154,
       "field_names": [
         "doc_id",
         "title",
@@ -356,7 +356,7 @@
     },
     {
       "collection": "fin_product_collection",
-      "row_count": 191,
+      "row_count": 251,
       "field_names": [
         "doc_id",
         "title",
@@ -578,7 +578,7 @@
     },
     {
       "collection": "user_long_term_memory_v1",
-      "row_count": 24,
+      "row_count": 42,
       "field_names": [
         "memory_uuid",
         "content",