换基线：说清「新底座里多出来的到访不会进导出包」，并把它钉成用例

写文案时去核这条，先把一条写错的断言纠正了：导出条数本来就不等于站点条数。

tableWriter.finish() 是两段：先删「基线里有、PG 已没有」的行（known − seen），
再把「导入时进不了 PG 但留档还在」的行（w.skipped × raws）按原样补回——否则
「导入→导出」一趟会凭空少数据。实测 823 条到访的数据集导出包里是 824 条，差值正常。
（第一版成功路径用例断言「导出 == 站点」，红在 824 != 823 就是这个原因；已改成更锋利的
「换底座前后导出包里 ZVISIT 的 UUID 集合逐条一致」。）

同一段代码定下了换基线的语义：新底座里站点没有的行会被清掉（进 known 没进 seen）。
所以换一份更新的手机包**不会**把手机新记录带进导出包，要带得先走「分析差异」合并。
页面提示与 flash 文案都写明了这点，并新增用例
TestSwapBaselineDoesNotCarryRowsTheSiteDoesNotHave 钉住它（站内补一条到访 → 导成包 →
从站内删掉 → 换底座 → 断言导出里既没有那条的派生 UUID、UUID 集合也与换之前逐条一致）。

验收：./scripts/verify.sh 全量 PASS=319 FAIL=0 SKIP=0。

internal/web/templates/admin/baseline.html

@@ -111,6 +111,11 @@
       判据有两条——这份包得跟当前数据集是同一批数据（按到访 UUID 认），而且得真的能导出成功。
       换之前旧底座会留档，随时可以回滚。
     </div>
+    <div class="alert">
+      <strong>注意</strong>：导出的行集合以<strong>站点数据</strong>为准（另加少量「导入时进不了站点、
+      靠原始留档补回」的行），所以这份包里如果有站点还没导入过的到访（手机上新记录的那些），
+      它们<strong>不会</strong>进导出包。想让它们进包，先用后台的「分析差异」把这份备份合并进来，再来换底座。
+    </div>
     <form method="post" action="/admin/baseline" enctype="multipart/form-data">
       <div class="row" style="align-items:center;flex-wrap:wrap">
         <input type="file" name="backup" accept=".rondbackup,.zip" required>