修性能回归：把「已并入 / 子段」判据做成派生列（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/web/backup_merge.go

@@ -761,6 +761,10 @@ func (s *Server) applyDeletions(ctx context.Context, ex execer, dsID int64, plan
 // 到访数与停留按**访客口径**（不含已并入 / 子段，见 stats.SoloVisitSQL），与 stats.Filter 一致；
 // 首末到访与数据集计数保持全量（last_visit_at 会写进导出包，datasets.visit_count 是后台口径）。
 func (s *Server) recountPlaces(ctx context.Context, ex execer, dsID int64) error {
+	// 先把派生列刷新（合并刚插进来的行带着留档），下面的聚合读的就是它
+	if _, err := ex.ExecContext(ctx, stats.RefreshMergedFlagsSQL, dsID); err != nil {
+		return err
+	}
 	if _, err := ex.ExecContext(ctx, `UPDATE places SET visit_count=0, dwell_minutes=0,
 		first_visit_at=NULL, last_visit_at=NULL WHERE dataset_id=$1`, dsID); err != nil {
 		return err