chore(product): 废弃并删除 db/sync_sku_master.py

与上一并废弃的 sync_dim_style.py 同类问题，且更彻底：

- 身份列自投影：脚本读 runtime_workflow_configs()（现已直读 dim_style），
  再把 jd_spus/dy_spus/tm_spus/jd_self_skus/erp_codes 全量 EXCLUDED 覆盖写回
  dim_style。对「同系列只填主款平台编码」的子款，它会走动态配置兜底把旧商品 ID
  反写，绕过系列共享规则
- 唯一还写的 bitable_sku_master_url/base/table 是 sales_bitable_url 的副本：
  生产库 24 行与 bitable_weekly_* 完全相同、无一行独有，且采集端、data-hub
  后端、运维脚本均无任何读取点（data-hub 审计文档标注「flow 只写，全生态不读」）

删除后款式身份的唯一写入口是 data-hub「产品生命进程」建档页。
bitable_sku_master_* 三列保留在库中不删（存量值不动，需要时可低成本恢复）。

- 删除 src/gyxx_flow/modules/product_commerce/db/sync_sku_master.py（170 行）
- 移除 config/runtime-bindings.json 绑定（cdp_port 22071）与 source-manifests 条目
- 测试计数同步：PRODUCTION_PYTHON 64 -> 63，集成绑定 157 -> 156
- docs/dynamic-workflow-config.md 合并两个废弃脚本的说明

验证：tests 根级套件 11 failed / 820 passed / 1 skipped，与改动前一致。

tests/test_runtime_integrations.py

@@ -103,9 +103,9 @@ def test_project_registry_covers_every_script_with_unique_stable_port() -> None:
     )
 
     assert len(scripts.command_ids) == 61
-    assert len(first.command_ids) == 157
+    assert len(first.command_ids) == 156
     bindings = [first.binding_for(command_id) for command_id in first.command_ids]
-    assert len({binding.cdp_port for binding in bindings}) == 157
+    assert len({binding.cdp_port for binding in bindings}) == 156
     assert all(22000 <= binding.cdp_port <= 22999 for binding in bindings)
     assert all(binding.cdp_url.startswith("http://127.0.0.1:") for binding in bindings)
     assert bindings == [second.binding_for(item.script_id) for item in bindings]