修性能回归：把「已并入 / 子段」判据做成派生列（visits.is_merged）

昨天给「已并入 / 子段」做的收口写成每行去 entity_raw 判
`raw->>'ZMERGEDTO' IS NOT NULL OR raw->>'ZPARENT' IS NOT NULL`，而 entity_raw.raw 是
**TOAST 过的整行 Core Data JSON**：一次探针要取回并解析整行。地点库「每个地点 × 5 个子查询」
的量级下 —— 实测 /places 70.1 秒、首页 43.6 秒才出页面（而库里没有任何一条 SQL 超过 1 秒：
时间全花在成千上万次「取整行再解析」上，进程 CPU 只用了 3s/135s）。

这批「渲染若干页面」的布局用例因此从 20 秒涨到 226~309 秒，整套验收从 6 分钟变 20+ 分钟。

- schema.sql：加派生列 visits.is_merged + 回填 + 给回填用的部分索引
  （只索引确实带合并标记的那几十行，不用取回 raw）。
- stats.SoloVisitSQL 改成读这一列（判据仍然只此一份，读侧全部经由它）。
- 写入侧跟着刷：ingest 在 insertEntityRaw 之后、backup_merge 的 recountPlaces 里，
  共用 stats.RefreshMergedFlagsSQL。
- 直接改留档里的合并标记（工具脚本 / 用例）之后也要刷一次，schema.sql 与函数注释都写明了。

实测：/places 70084ms → 206ms，/ 43633ms → 698ms（比「关掉判据」的对照还快）。
新增 page_render_budget_test.go：给 7 个关键页卡 10 秒上限的灾难探测器
（功能全对、只是慢的那种退化，之前没有任何用例会红）。

internal/ingest/ingest.go

@@ -376,6 +376,12 @@ func Import(ctx context.Context, db *sql.DB, userID int64, originalName, sha str
 		return 0, nil, err
 	}
 
+	// 派生列：从留档里认「已并入 / 子段」的到访（读侧只看这一列，见 stats.SoloVisitSQL）。
+	// ⚠️ 同样必须排在 insertEntityRaw 之后——留档还没写盘时一条都认不出来。
+	if _, err := tx.ExecContext(ctx, stats.RefreshMergedFlagsSQL, datasetID); err != nil {
+		return 0, nil, fmt.Errorf("回填合并标记: %w", err)
+	}
+
 	// 回填地点聚合：走与刷新路径（refreshPlaceAgg / recountPlaces）同一条 SQL，
 	// 口径才不会在两处漂移——到访数与停留按访客口径（stats.SoloVisitSQL，不含已并入 / 子段），
 	// 首末到访保持全量。原来这里在 Go 里另算一遍，还漏了停留上限（LEAST(...,10080)）。