fix(schedule): 补排期两张静默停摆 65 个交易日的事件表 + 新增排期覆盖审计
问题（用户报告）
----------------
`stk_holdertrade`（股东增减持）与 `repurchase`（股票回购）双双停在
`20260618`，而行情已到 `20260917` —— **停摆约 65 个交易日且无任何告警**。
根因
----
两张表在 `cli.py` 的 `_TYPE_TABLES` 任何分组里都不存在，也不在任何
`--tables` 列表里 —— **从未被任何调度任务调用过**。
`config.yaml` 里的 `tables:` 启用开关不救场：该开关只在
「未显式指定要抓哪些表」时才生效（`fetcher.py:239-243`），
而两个 launchd 调度脚本总是显式传 `--type` / `--tables`，开关被完全绕过。
于是「配置里写着 true」与「实际在不在跑」是两件事，且没有任何对账机制。
改动
----
1. `scripts/tushare_sync.sh` 补排期
- daily：新增 `stk_holdertrade,repurchase`
- monthly：新增 `fund_div,fund_manager,fund_share,fund_nav`
2. 新增 `Scripts/bin/audit_schedule_coverage.py`
把三份来源交叉对账：TABLE_MAP 定义 / 调度实际覆盖 / config 声明启用。
输出「启用但无任何排期」的真缺陷清单与「孤儿且未声明」的参考清单。
—— 这类缺陷的特征就是**静默**，必须有机制主动对账。
补数结果（实测）
----------------
stk_holdertrade 51,030 → 52,937 行，最新 20260618 → 20260918
repurchase 43,584 → 45,901 行，最新 20260618 → 20260918
最近交易日分布正常（20260918 新增 11 条、20260917 新增 29 条）
审计复核
--------
调度覆盖 55 → 61 张；「启用但无排期」真缺陷 12 → 7 张
仍未处理（本次已查明，需单独决策）
----------------------------------
剩余 7 张「启用但无排期」中，6 张**表根本不存在**，从未建过：
hk_hold / shibor / stk_managers / stk_rewards / ths_daily / us_daily
（需先建表 DDL 再首次全量加载，属独立工作量）
另有 `stk_factor`：接口限 5 次/天，**无法批量抓取**，
`fetcher.py` 已显式跳过并打 WARNING —— 应从 config 里改为停用，避免长期假"启用"。
另有 44 张「孤儿且 config 未声明」的历史表，需人工确认是否应纳入采集。
FinDataHub
6456fcd299