docs(douyin-mashida): 补平台真实推送的实测形态

订阅生效后一笔真实付款的推送原文（来源 IP、耗时、字段值）：
- p_id/s_ids 是 19 位裸数字，pay_time 是秒级 —— 与 §4.1 精度修复、§4.8 双形态解析相互印证
- 记录文档未覆盖的 pay_type=8，代码不依赖该字段
- 端到端：付款 12:55:05 → 推送 12:55:11 → 建单+发券+syncV2 完成 12:55:12

docs/抖音-码速达/00-总览.md

@@ -251,6 +251,7 @@ git add apps/backend/src/app.ts \
 | 19 位订单号精度 | ✅ `6930310175251856483` 精确保留 |
 | `coupons.syncV2` 同步到真平台 | ✅ `sync_status=success` |
 | 兑换页状态 | ✅ `redeemable`，展示真实商品名与真实支付时间 |
+| **平台自动推送**（订阅后真单付款） | ✅ 6 秒到达，来源 IP `118.31.56.230`，端到端约 7 秒完成建单+发券+同步 |
 | `pay_time` 字符串形态 | ⚠️ 实测发现并已修复（见 07 §4.8） |
 | `messagetest` 自测入口 | ⚠️ 始终 `20006 data参数内容解析异常`，未探明其 data 要求；不影响真实链路 |
 

docs/抖音-码速达/07-最小接入实现说明.md

@@ -151,13 +151,27 @@ applyRawBigIntegerOverrides(parsed, rawText)   // p_id / order_id / s_id / s_ids
 不是文档示例里的 `77977`；`sku_order_list[].order_id` 是**字符串**，本例与父单号相同。
 联调时以真实响应为准。
 
-### 4.10 平台推送是**订阅制**（不配就永远收不到）
+### 4.10 平台真实推送的形态（实测抓到的原文）
+
+订阅配好后，一笔真实付款的推送**约 6 秒**到达，来源 IP 是平台服务器（`118.31.56.230`），
+body 原文（注意 `p_id`/`s_ids` 是**裸数字**、`pay_time` 是**秒级**）：
+
+```json
+{"biz":11,"order_status":2,"order_type":5,"p_id":6930292726686514275,"pay_amount":100,
+ "pay_time":1791521705,"pay_type":8,"s_ids":[6930292726686514275],"shop_id":305760014}
+```
+
+- `pay_type=8` **文档里没有**（文档只列了 0/1/2），代码不依赖该字段，仅记录备查；
+- `p_id` 是 19 位裸数字 → 正好验证了 §4.1 的精度修复（落库/回执全程精确）；
+- 端到端耗时：付款 12:55:05 → 推送 12:55:11 → 建单+发券+`syncV2` 完成 12:55:12。
+
+### 4.11 平台推送是**订阅制**（不配就永远收不到）
 
 填好 `uid`/`secret` 只代表我们能调平台，平台**不会**自动推消息过来：
 必须调「消息设置」`message.config` 配置 `message_url` + `topics` + `status=1`。
 而且**不补推**订阅之前的历史订单。详见 [08-公网联调.md](08-公网联调.md) §2。
 
-### 4.11 退款/取消消息文档没列字段
+### 4.12 退款/取消消息文档没列字段
 
 `refund_*`、`trade_TradeCanceled`、`trade_TradeSuccess` 这几条文档里 `props` 是空的（很可能只是文档缺失）。
 代码按「有 `p_id` 就作废券、没有就留痕等人工」处理 —— **不抛错**，避免平台无意义重推。