feat(iot_mqtt): 快速上报增加 car_state 翻转沿触发

- Step2: 任一通道 |variation|>=阈值 或 car_state 翻转沿, 均进入 300ms 快速档
  (高灵敏度档小车 variation 可能不过阈值, 但 Loop 已判翻转, 事件不应慢发)
- 修复首版两坑: if(fast_mode=0) 单等号致沿检测死代码;
  快照刷新移到间隔门控之后, 防止沿被门控吞掉后退化为空闲慢发
- gcc 隔离单测: buggy 沿后延迟 950ms vs fixed 250ms, 出车沿/负向variation回归通过
- devlog 补 2026-07-15 条目

vd960DBN/docs/devlog.md

@@ -6,6 +6,34 @@
 
 ---
 
+## 2026-07-15 — MQTT 快速上报增加 car_state 翻转沿触发
+
+### 背景
+
+原 fast_mode 仅由 `|variation| >= 10` 触发。灵敏度设高档时小车信号弱，variation 可能不过阈值，但 Loop MCU 已判定 car_state 翻转——进/出车事件仍按空闲间隔（≥1s）慢发，后台看到的过车时刻误差大。故增加：**任一通道 car_state 翻转沿也触发 300ms 快速上报**。
+
+### 实现要点（两个坑，首版都踩了）
+
+1. **`if (fast_mode = 0)` 单等号** → 赋值恒假，沿检测死代码。修正为直接判断（循环内走到该行 fast_mode 必为 0，无需再判）。
+2. **快照刷新必须在间隔门控之后**。若在门控前无条件刷新 `_last_car_state`，沿被门控吞掉（如距上次发布 <300ms）时快照已同步，下一轮检测不到翻转 → 事件退化为空闲间隔上报。修正：`return`（未到间隔）时不刷快照，沿保持"待发"持续顶住 fast_mode，直到真正发布才同步。
+
+```c
+/* Step 2 循环内: variation 阈值 与 car_state 沿, 任一命中即 fast */
+if (av >= IOT_MQTT_VARIATION_THRESHOLD) { fast_mode = 1; break; }
+if (_last_car_state[i] != coils[i].car_state) { fast_mode = 1; break; }
+
+/* Step 3 门控通过后才刷新快照 */
+for (i = 0; i < coil_count; i++) _last_car_state[i] = coils[i].car_state;
+```
+
+### 验证
+
+本地 gcc 隔离单测（buggy vs fixed 对照）：进车沿后 buggy 延迟 950ms（退化空闲间隔），fixed 250ms（≤300ms 快速档）；出车沿、负向 variation 回归均通过。
+
+⚠️ 上电首帧若已有车（`_last_car_state` 初值 0 vs car_state=1），会触发一次 fast_mode——属良性，首帧本就该尽快发。
+
+---
+
 ## 2026-07-14 — Loop 上报 variation 解析升级 2B→3B 有符号 (协议 V1.05)
 
 ### 背景