feat(entity-dim): 账套维度收口批 — subjects/analysis_results 加列 + 分析结论账套化 + 模板实例化构造点补账套

- ① kpi_templates instantiate 构造点显式传会话账套（原缺 entity_id ⇒ 静默落 e1），kpi_code 判重按账套收紧
- ② kpi_subject_map 3 个读取点加护栏注释（不加列、不改语义）
- ③ subjects 分层：读口 union（NULL=全局标准准则科目 / N=账套私有），UPSERT 唯一键改 (entity_id, subject_code)
- ④ analysis_results 账套化：读/写/删三端点按会话账套判定归属（列未落地时 kpi_code JOIN 止血），
     无归属行进 unattributed 登记、删除一律 404
- 模型层按现网 DDL 补齐：KPIDefinition(template_id/is_system + uk_entity_kpi)、AnalysisResult.entity_id、Subject.entity_id
- 新增 migrate_{subjects,analysis_results}_entity_id_20260923.py（--check/--apply/--down）、
  22 条对账用例 test_entity_dimension_convergence_20260923.py

DDL 已由 ops 受控通道落地（subjects 21:31:56 / analysis_results 21:31:59 CST，审批 1e9b4d9a/5ffb1640）
本提交为切片提交，未 push（发布须另取放行）

backend/app/api/ontology.py

@@ -45,12 +45,22 @@ def trace_ontology(
     )
 
     # 第3层: 每个 KPI 依赖的科目 (kpi_subject_map)
+    # ⚠️ 护栏（2026-09-23 账套维度收口批 ②，零结构改动、零读取逻辑改动）：
+    #    该表是唯一一张「语义上必然账套相关、却无账套列」的表 —— **账套维度经 `kpi_id` 继承**
+    #    （`kpi_definitions.entity_id`，本函数先按 `Objective.entity_id` 过滤目标、再按 kpi_id 取映射）。
+    #    **禁止新增按 `subject_code` 反查的读口，禁止按 `subject_code` 批量写的入口**：
+    #    科目码在标准准则体系里两账套同义（同一 code 可属不同账套），按科目反查/批量写立刻跨账套。
     subject_by_code = {
         s.subject_code: s.subject_name
-        for s in db.query(Subject).filter(Subject.is_active == 1).all()
+        for s in db.query(Subject).filter(
+            Subject.is_active == 1,
+            # 账套分层（2026-09-23 subjects 加 entity_id 列）：全局标准科目 ∪ 本账套私有明细
+            (Subject.entity_id.is_(None)) | (Subject.entity_id == entity_id),
+        ).all()
     }
     kpi_layer = []
     for link, kpi in links:
+        # kpi_id 已由上方 Objective.entity_id 过滤链继承账套维度（见护栏注释），故此处不再按科目口径过滤
         maps = (
             db.query(KPISubjectMap)
             .filter(KPISubjectMap.kpi_id == kpi.id)