docs(api): 补充 N+1 约束与缺失期计算说明到 API_REFERENCE §4.48.1

按本轮实现事实更新文档：
- 在 §4.48.1 脚注区增加 SQL 预算小节（报告指标 ≤5、quickLookup/sourceTypes 恒 1 次查询），
  并说明上一期与 periodCount 全部内存计算，避免后续维护者再写成逐指标回查。
- 注明 missingPeriods 固定 2 次查询的优化结果（原先 1+缺失期数会 N+1）。

docs/superpowers/api/API_REFERENCE.md

@@ -1754,7 +1754,9 @@ interactionType 取值：`PHONE` / `WECHAT` / `MEETING` / `OTHER`。
 | `POST /api/indicator/source-types` | 出参新增 `periodCount` / `latestReportDate`（曲线页类型筛选用，原只返回类型名）。**破坏性：无** |
 
 > **`chartMode` 判定表**（后端单点定义，`IndicatorChangeService.chartModeOf`）：`pointsCount=0 → empty`；`=1 → single`；`=2 → pair`；`<20 → line`；`≥20 → line_aggregated`（`granularity=month` 时强制 `line_aggregated`）。
+> **SQL 预算（严禁 N+1，均有单测锁死）**：`/report/indicators` 42 项指标 → 服务层恒 3 次协作调用（控制器另加 2 次，合计 ≤ 5）；`/quick-lookup` 与 `/source-types` 均恒 1 次 `indicator_values` 查询（上一期与 `periodCount` 全部内存计算）。
 > **`IndicatorService.listDefinitions`**：`status` 传 null 时**默认按 `status=1` 过滤**（防止 P1-6 自动创建的 `status=0` definition 冒进管理端字典列表，QP17）。
+> **`missingPeriods`**：该成员有报告、但本指标无有效值的期次，`IndicatorTimelineService` 固定 2 次查询算完（原 1+缺失期数，会 N+1）。
 > **老接口兼容矩阵**见 `specs/2026-10-25-indicator-timeline-display-design.md` §4.7。
 
 *文档更新：2026-10-27（指标多期展示 T02 后端接口，见 `specs/2026-10-25-indicator-timeline-display-design.md`）*