提交统计未按作者过滤

关于页热力图的提交数从 412 降至 376，若干日期的色阶随之下降。这一区间内排除了 39 条他人提交，同时另有 3 条新提交计入，净减 36 条。被排除的部分来自一处未按作者过滤的统计逻辑：另一个 agent 在 Bingu 仓库产生的提交被计为博主本人的活动。

统计脚本按提交日期聚合，未对作者做筛选。仓库维度的隔离在此处不成立——统计口径是账号，而账号下包含多个仓库。

引入作者邮箱白名单，仅统计名单内的提交。

这里有一处不能按直觉判断的边界：白名单不能由「邮箱是否已在账号上验证」推导。博主历史提交中有 292 条使用的邮箱从未在账号上验证，按验证状态筛选会把这些一并排除。

脚本运行结束后输出被排除的作者及其提交条数。新增的机器身份由此进入可见状态，而不是被静默丢弃。

同一类问题此前已出现过一次：统计范围曾包含第三方镜像仓库 bilibili-api-collect。该仓库不属于博主，账号本人在其中有 0 条提交，全仓共 1219 条提交、239 个外部作者、523 个活跃日。全历史口径下，混入使活跃日从 76 涨到 597，差 521 天；而渲染只看最近 52 周，这 521 天里绝大部分从未上过图。热力图窗口内该仓库只有 11 条提交，落在 6 个日期：其中 4 天整格变空（2025-11-06、11-16、2026-01-11、01-21），2 天掉一档（01-19、01-22）。受影响的是 6 个格子，不是 521 个。

判定不能靠「是否 fork」：该仓库在 GitHub 上 fork 为 false，无 parent、无 upstream，是 2026-01-29 一次性导入的重新上传，fork 检查抓不到它。

现行规则里真正保住正确性的只有一道：把提交作者邮箱与账号本人比对，镜像仓的 1219 条在这一步全部归零。仓库白名单（只拉账号名下的四个仓库）限定的是统计范围与开销，不是正确性——保留镜像仓、只用邮箱白名单跑一遍，窗口内每天的数与现状完全一致。两道白名单的关系容易写反，按「各挡一类、缺一不可」写会让读者以为少一道结果就错。