fix(fetch-caliber): 取数层排除半年/预测伪期间 + subjects 响应补 entity_id

R3 期间口径（仅 YYYY-MM）延伸到取数层：新增 alert_entity_scope.month_period_clause()（跨库可移植 SQL 等价式），应用到 15 个文件 26 处「按 period 倒序取最新值/最近N期」位点；dashboard 原 MySQL-only REGEXP 正则收口到同单一事实源。

GET /api/cma/subjects 响应增补 entity_id（NULL=全局标准准则科目 / N=账套私有明细），既有 10 字段语义与名称不变。

证据：pending-tasks/_reports/yanxue-20260924-cma-fetch-caliber-fixes-fullstack.md（改前/改后 A/B：F_NET_PROFIT 2026-H2/-55.0 → 2026-08/-10.46）。新增 7 例回归测试；全量 1 failed(预存在) 1473 passed，基线同项。

backend/app/utils/alert_entity_scope.py

@@ -87,6 +87,36 @@ def period_in_window(period, now: Optional[datetime] = None) -> bool:
     return str(period) >= window_lower_period(now)
 
 
+def month_period_clause(column):
+    """R3 的 SQL 等价式：`column` 必须落在规整月 `YYYY-MM`（供**取数层**查询使用）。
+
+    为什么取数层必须是 SQL 侧（而不是取完再在 Python 里挑）：
+      取数层的动作是「`ORDER BY period DESC` 取最新一行」（`.first()` / `.limit(N)`）。
+      伪期间 `2026-H2` 的**字符串序大于任何同年月份**（'H' > '0'），所以只要它留在排序里，
+      「最新实际期」就被它顶掉——取到的是**预测值/半年值**，而且 Python 侧再过滤也救不回来
+      （最新那一行已经不是月期间，第二行才是），`.first()` 的结果直接变成错值或空。
+      故本口径必须在 **SQL 侧**参与排序前的筛选。
+
+    跨库可移植：只用 `LENGTH` / `SUBSTR` / `BETWEEN` / `IN`（MySQL、SQLite、PostgreSQL 同名可用），
+    **不用 `REGEXP`**——SQLite 测试库未注册 REGEXP，SQL 侧正则会让单测与生产走两套语义。
+
+    与 Python 侧 `is_month_period` 同源等价：长度 7 + 第 5 位 `-` + 月份两位数字且 01–12
+    （`2026-13` 之类非法月同样排除）。禁止在调用点另写一份长度/正则判断。
+    """
+    from sqlalchemy import and_, func, or_  # 局部导入：本模块顶层不依赖 sqlalchemy 表达式 API
+
+    tens = func.substr(column, 6, 1)
+    ones = func.substr(column, 7, 1)
+    return and_(
+        func.length(column) == 7,
+        func.substr(column, 5, 1) == "-",
+        or_(
+            and_(tens == "0", ones.between("1", "9")),
+            and_(tens == "1", ones.in_(["0", "1", "2"])),
+        ),
+    )
+
+
 # ── 裁定 2b（2026-09-17）：「各 KPI 自己的最近可用期间」，单一实现 ──
 #
 # 2026-09-25（ASK-20260924-15）：原实现只在 `scripts/alert_generator.resolve_latest_period`，