[STARDUSTLC666]

修复 #274（core/结构重要性）：recalc_structural_importance 的「因果上游度」不再让低价值扇出越阈授予永久保护，并跳过归档/驳回节点与悬空边。

背景：#269 已把上游度传播限制为「只统计 verified=1 的 causal 边」；本 PR 补的是同一函数的另外三面（#274 原文点名、#269 边界明确「不在本件」）。

改了什么 / 为什么

• 低价值扇出：concept_influence 只让 importance >= 0.7 的下游节点贡献。旧实现 4 条已验证、confidence 0.5、下游 importance 0.5 的边即 4×0.5×0.5 = 1.0 ≥ protect_threshold，把一条 0.3 的普通纪要 protect_node + no_forget 并抬到 0.9。
• 归档/驳回：重算循环读出 tags，跳过 archived / refuted / deprecated 节点——旧实现会把 importance=0.1 的已归档节点拉回 0.9 并重新登记保护，抵消 forget_advisor。
• 悬空边：BFS 中目标节点已不存在时不再用默认 importance=0.5 计分（下游删光后上游仍被保护的路径消失）。

验证方式与读数

# 改前（3552ec3）
4 条 verified/0.5/下游 0.5 -> protected=1，hub 0.3→0.9，no_forget=True
archived+refuted 节点       -> imp 0.1→0.9，重新进保护名单
下游全删、悬空边            -> 上游仍被保护

# 改后
4 条 verified/0.5/下游 0.5 -> protected=0，不在名单、无 no_forget
archived+refuted 节点       -> imp 保持 0.1，不在名单
悬空边                      -> 不计分，不保护
单条强因果（下游 1.0/conf 1.0） -> 仍保护（对照）
#269 正例（3 条 verified/下游 0.8） -> 仍保护（回归绿）

python -X utf8 tests/test_issue274_structural_influence_guard.py            # 通过 8 / 失败 0
python -X utf8 tests/test_issue274_structural_influence_guard.py --mutate   # 3 条变异各自恰好命中
# 基线对照（origin/main core.py）：通过 2 / 失败 6
python -m pytest tests/test_issue257_decay_protection_cliff_guard.py \
  tests/test_issue269_unverified_edge_protection_guard.py \
  tests/test_issue299_structural_importance_idempotent_guard.py -q   # 9 passed

实测	未改基线 3552ec3	本分支
4 条 verified/0.5/下游 0.5	保护 + 0.9 + no_forget	不保护
单条强因果（下游 1.0/conf 1.0）	保护	保护（不变）
archived/refuted 节点	拉回 0.9 + 保护	保持 0.1、不保护
悬空边	按 0.5 计分并保护	不计分
#257/#269/#299 回归	9 passed	9 passed

具名反面对照（--mutate）

• M1 撤「下游 importance ≥ 0.7」门槛 ⇒ A01 + E01 红。
• M2 撤 archived/refuted/deprecated 跳过 ⇒ B01 红。
• M3 悬空目标回落默认 1.0 ⇒ C01 + E03 红。

三条变异各自恰好命中期望红集；变异后源码字节级还原。

边界与不做项

• 不做保护撤销（issue 建议 4）：protections 无 TTL，撤销面属 [core/情境层·遗忘] 保护名单只增不减，decay_cycle 却把它展开成 2N 个 SQL 占位符：长期记忆累计超过 16383 条后每轮衰减都抛 too many SQL variables，情境层、边衰减、睡眠巩固永久停摆，无自愈路径 #257/[core/遗忘][M7] 保护名单被逐个展开成 SQL 绑定参数：受保护节点数一过「SQLite 变量上限 / 2」（旧版 SQLite 仅 500 条，上游默认 16384 条），decay_cycle 每轮抛 too many SQL variables——整个遗忘引擎永久停摆，睡眠巩固跟着全挂，后台衰减线程静默死亡且无法重启 #261 的保护名单回收范畴；本件只保证不再新增误保护。
• 不做全局归一化（按出度/路径数）：会破坏 [core/结构重要性] recalc_structural_importance 凭 3 条未验证的默认边就把节点永久保护并把 importance 抬到 0.9：保护后这些边自己也不再衰减，撤掉全部边后保护仍不撤销——一条随口猜想变成永不遗忘的「上游概念」 #269 的正例（3 条已验证、下游 0.8 应保护）；改用「下游 importance 门槛」保留该判别力。
• 既有误保护不迁移：修复前已登记的 no_forget 行仍永久生效（需人工/另案清理）。
• 未测：Linux/WSL 复跑（本机 Windows 读数）；全量 CI。

Fixes #274

[FuRongJun-1999]

维护侧处置（值守第 149 轮）

你的修复已采纳并合并：维护侧以你的分支头（22eaede，含你自补的 gate.yml SCRIPT_TESTS 接线与 core.py 指纹同步）镜像为 PR #1156 合并（9d71377）——修法、守卫与自补丁均为你的净增量原样（署名与致谢见 #274 关闭帖）。

未直接合并 #1152 的原因：分支基线早于维护侧 #1138/#1143/#1146，直接合并会回退已合工作。

本端读数：守卫 8/8 于 main；#691/#299 邻面 5 passed 无回归；CI 4/4 绿。感谢高质量修复——自带 --mutate 自证与「削掉的判别力如实钉住」（G 组）的守卫设计是范本。