yml2213
c8a4b7e945
fix(worker): 删除依赖残留字段 task_id 的死 JOIN，店铺名兜底改读 material_json
核查结论：work_orders.task_id 是残留字段，不是"数据没同步上来"。
1. 唯一写入点 createWorkOrder 写的是 input.taskId || null，而两个调用方
一个硬编码 taskId: null、一个根本不传；updateWorkOrder 的白名单里也没有它；
git 全历史检索 `taskId:` 只出现过 null 一种取值。
2. 即便强写也无从关联：工单关联 100,231 个订单、履约任务关联 87,603 个订单，
交集为 0；按 order_item_id 比对 100,229 条同样 0 命中。而两者时间范围
（2026-07~10）与 orders.id 区间（1~280k）都重叠 —— 说明是按规则表分流的
两条并行履约通道，一单只走一条。
3. 依赖它的 idx_work_orders_task_unique 为空（8KB）。
改动：
- 三处 `LEFT JOIN fulfillment_tasks ft ON ft.id = wo.task_id`
（取消申请 / 售后案 / 工单反馈）恒为空，删除；
- 店铺名兜底 `ft.shop_name/shop_id` 改为读工单自己的
material_json->'source'->>'shopName'/'shopId'；
- 取消申请里的 `ft.platform_order_id` 一并删除（实测 needs_ft_pid_fallback = 0，纯 no-op）；
- 迁移 091 给列与索引打上注释，避免后续再被当成数据问题重复排查。
生产逐行回归（旧逻辑 vs 新逻辑取差集）：
取消申请 715/715 行、103 条店铺名从空变有值、回归 0；
售后案 21/21 行、1 条、回归 0；工单反馈 348/348 行、15 条、回归 0；
合计 119 条修复、0 条回归、行数与 platform_order_id 零变化。
验证：新增源码级守卫（禁止再 JOIN fulfillment_tasks、兜底必须读 material_json）。