fix(schedule): 建齐 17 张缺表让排期生效，并摘除 7 张不可采表
问题
----
排期前飞行检查（dry-run 只校验表名解析，不校验表是否存在）发现：
`tushare_sync.sh` 引用了 **21 张库中不存在的表**（fut_* / fx_* / hk_* / us_* /
opt_daily / sge_daily / ths_index / rate_* …）。因缺表只记 `写入失败` 日志、
**退出码仍为 0**，带 pipefail 的脚本也不会 abort —— 表现为这些行**长期静默空转**，
与用户报的 stk_holdertrade 停摆是同一类缺陷。仓库此前没有任何机制发现它。
改动
----
1. 新增 `Scripts/bin/create_missing_tables.py`
- `--list` 列出「排期引用但库中不存在」的表
- `--dry-run` 打印将执行的 DDL
- `--create` 幂等建表（已存在则跳过，不 DROP、不改既有结构）
- 从 **Tushare 接口实际返回的 DataFrame 推导列与类型**：仓库里
`tables_registry.json` 只登记表名/唯一键/日期列、**不含字段定义**，
而 DDL 必须与写入时的 `df.columns` 一致，否则 upsert 整批失败。
- 入参采用**阶梯重试**（ts_code / trade_date / start+end / 无参）：
实测不同接口要求不同入参，且部分接口有 1 次/分钟限流，单次失败不代表不可用。
2. 建表结果：**成功 17 张**，首次加载已入库 **2,708,881 行**
（fut_daily 960,979 / fut_holding 1,800,000 / fut_trade_cal 13,527 /
fut_basic 10,000 / hk_basic 2,785 / rate_gz_index 1,181 …，其余后台继续）
3. 摘除 7 张**确认不可采**的表，并在 config.yaml 标注确凿原因（附实测报文）：
- `libor` / `ths_index` / `ths_daily` / `stk_factor` —— **无接口访问权限**
- `hibor` / `shibor_lpr` / `us_daily` —— 配额 **1 次/小时**，无法按日迭代采集
复核（两条独立检查）
--------------------
- 排期涉及的 **80 张表在库中全部存在** → 下午 15:40 的日更不再有空转行
- 15 条 fetch 命令 dry-run 全部可解析；配置经 YAML 解析校验
过程中修正的两处自身错误
------------------------
1. 首次探测把 `TABLE_MAP` 元组里**第 1 个**引号串当作 api_name（实为库表名），
导致 `shibor`/`stk_managers` 等被误判为「接口名错误」；取第 2 个才是 api_name。
2. DDL 推导首版对 `str(dtype)` 做字符串匹配 —— pandas 3.x 字符串列 dtype 显示为
`str`，导致 `ts_code`/`name` 被误生成为 `double`。
改用 `pd.api.types.is_numeric_dtype()` 等类型谓词后，可疑列归零。
回归
----
tushare 174、core 121、akshare 183、Scripts 213、kuaixun 410 = 1101 passed
FinDataHub
a4b2cf11d7