debug(rf): revert to polling EV1527_Decode, ISR does pure edge counting

Diagnostic experiment: restore the commit d8df5d4 polling decode
algorithm/thresholds unchanged, while P3.6 ISR now only increments an
edge counter (no decode state machine). Successful decodes print the
edge-count delta over the decode window to compare against the
EV1527 theoretical 50-edges-per-frame, to validate/refute the
edge-interrupt glitch-noise hypothesis.

work-order/wo-04

@@ -142,7 +142,20 @@
 * P3.6 双边沿中断现在身兼两职：休眠期间做唤醒源 (`p3_wakeup_flag`)，正常运行期间驱动 `RF_HandleEdgeInterrupt()` 解码；`Enter_Low_Power_Sleep`/`Wakeup_Restore` 中对应调整为"不再清零 P3.6 的中断允许位"，避免唤醒后 RX 解码功能失效。
 * 尚未实机编译烧录验证，第三节验收标准仍需在真实硬件上逐项确认 (尤其是干扰环境下的解码成功率、休眠唤醒功能是否受影响)。
 
-### 2.6 实机验证发现的问题与修复：P3.6 悬空引发中断风暴，导致开机卡死
+### 2.7 实机验证发现的真正根因：Port3 中断向量重定向缺失 + isr_jump.asm 从未参与编译
+
+在 2.6 节的排查过程中，通过逐步二分法(先屏蔽 `RF_HandleEdgeInterrupt` 函数体、再屏蔽 `P3INTE`)最终定位到**真正的病根**，2.6 节"P3.6 悬空"的诊断被推翻，记录如下供后续参考：
+
+* `Drivers/stc32g.h` 里的官方向量表显示：P3 端口中断的真实硬件向量号是 **40**(地址 `0x000143`，`P3INT_VECTOR`)，而 [App/main.c](App/main.c) 里 `Port3_Isr` 声明的是 `interrupt 16`，对应的其实是向量 16 号 `INT4_VECTOR`(地址 `0x000083`，"外部中断 4"，与 P3 端口毫无关系)。
+* 向量号 40 超出 Keil C251 `interrupt` 关键字原生支持的 0~31 范围，跟 Port0(37 号)、Port2(39 号)一样，必须靠 [App/isr_jump.asm](App/isr_jump.asm) 里的汇编跳转表把硬件真实向量地址重定向到 C 代码能声明的低位向量——但这个文件里**只有 Port0、Port2 的重定向，Port3 这一条从建立以来就一直缺失**。
+* 更严重的是，进一步检查发现 **`isr_jump.asm` 这个文件本身从未被加入 `wristband.uvproj` 工程**，也就是说不止 Port3，Port0/Port2 的重定向指令这么多年也从未被真正汇编链接进过固件——这是这份代码库里一直存在、此前从未暴露的问题。
+* 之所以此前测试(尤其是低功耗休眠唤醒功能)没有暴露这个问题，推测是因为 P0/P2/P3 的中断使能窗口一直很短(仅在睡眠前临时打开、触发一次就自行关闭)，硬件的"从掉电模式被中断请求唤醒"这个动作可能不需要真正完成向量跳转就能生效，狭窄的时间窗口侥幸没有触发跳转到未写入指令的地址。本次工单把 P3.6 的中断改为开机后永久常开、且芯片持续真实接收产生大量边沿，第一次让这个跳转被稳定触发，问题才暴露出来。
+* **修复**(两处缺一不可)：
+  1. 在 `App/isr_jump.asm` 里补上 Port3 的重定向条目：`CSEG AT 000143H` → `LJMP 000083H`(跳转到 `interrupt 16` 即 `Port3_Isr` 的入口)。
+  2. 把 `App/isr_jump.asm` 加入 `wristband.uvproj` 工程文件(`FileType=2`，汇编源文件)，确保它真正参与编译链接。
+* 修复后，2.6 节里为排查而加的调试代码(`RF_HandleEdgeInterrupt` 开头的 `return;`、注释掉的 `P3INTE |= 0x40;`)均已撤销，恢复正常逻辑。
+
+### 2.6 实机验证过程记录：P3.6 悬空猜想(已被 2.7 节推翻，仅作排查过程存档)
 
 用户实测反馈：改动后开机背光闪一下就灭，按住开机键不放背光反复闪烁。排查确认根因：
 
@@ -153,6 +166,26 @@
   - `Drivers/rf.c` 的 `RF_Init()` 中新增。
   - `App/system.c` 的 `Wakeup_Restore()` 中新增恢复 (因为 `Enter_Low_Power_Sleep()` 休眠前为了省电特意把这个上拉关掉了，唤醒后要重新打开)。
 
+### 2.8 对照实验：轮询解码 + 中断纯计数，验证毛刺/降噪分析是否成立
+
+背景：中断增量解码状态机(2.2 节设计)接入真机后，`sync_seen` 长期为 0 或解码一直失败；调整"毛刺过滤下限" (`RF_GLITCH_MIN_TICKS`) 从 10us 逐步提高到 100us 的过程中，`ss_dur_max`/`ss_high_max` 等诊断量时而逼近理论值、时而超出合法区间，未能收敛到稳定结论。用户明确要求停止继续盲目调参，并提出一个可以直接证伪/证实"毛刺导致解码状态机误判"这一假设的对照实验：
+
+* 解码逻辑临时改回 commit `d8df5d4` 已验证长期稳定工作的阻塞轮询实现 (`GetPulseDuration()` + `EV1527_Decode()`，算法/阈值原样保留)。
+* P3.6 边沿中断 (`RF_HandleEdgeInterrupt()`) 同时保持使能，但只做纯计数 (`dbg_isr_edge_count++`)，不参与任何解码判断。
+* 轮询解码一旦成功，立即打印本次解码尝试开始前、成功那一刻的中断边沿计数快照及差值 (`[RF-ISR-CHECK] edges_before=.. edges_after=.. delta=..`)，与 EV1527 协议一帧的理论边沿数 (同步头 2 个 + 24 位数据每位 2 个 = 50) 比对。
+* 若 `delta` 稳定等于 50 (或在合理误差范围内)：说明真实硬件产生的边沿是干净、可信的，此前中断状态机解码失败的原因不在"信号本身有毛刺"，而在状态机代码逻辑本身；应转向复查状态机实现而非继续调整过滤阈值。
+* 若 `delta` 明显偏离 50 (尤其是远大于 50)：则支持此前"存在真实高频毛刺/回响，被边沿中断如实捕获，但被轮询的每次循环开销意外滤除"的分析，说明中断驱动方案需要额外做硬件或软件去抖，才能达到轮询版本的可靠性。
+
+改动仅限 `Drivers/rf.c`(`Drivers/rf.h` 同步更新函数注释)：
+
+* `GetPulseDuration()`：算法/阈值与原始版本一致，但测量方式改为对 `Drivers/timer.c` 提供的自由运行 `Timer0_GetTimestamp()` 做快照差值，而不是原始版本那样直接停表/清零/重启 `TR0`——因为现在 Timer0 已经是 `RF_Delay_us()`(TX 发射计时) 共用的自由运行时间戳源，若在这里停表清零会导致解码尝试之后的 TX 发射永远等不到时间戳前进而卡死。这是相对原始实现唯一的必要改动，不影响被验证的解码算法本身。
+* `EV1527_Decode()`：算法与原始版本一致，新增开始前/成功后的边沿计数快照打印。
+* `RF_HandleEdgeInterrupt()`：从三态状态机简化为纯计数器 (`dbg_isr_edge_count++`)。
+* `RF_PrintDebugCounters()`：简化为只打印 `isr_edge_count`。
+* 本实验阶段之前为诊断中断状态机新增的大量 `dbg_*` 计数器/`RF_CheckDecodeWatchdog`/状态机相关代码已随之整体移除；若后续证实需要回到中断驱动方案，需要从 git 历史重新引入或重新设计，不建议直接依赖本次删除前的调参结果。
+
+状态：代码已完成，待实机烧录，触发一次真实发射并观察 `[RF-ISR-CHECK]` 日志的 `delta` 是否稳定等于 50。
+
 ## 六、阶段 1 实现备注
 
 * 语言字节与传感器数据库共用同一 Flash 扇区(偏移地址为 `sizeof(sensor_list)`,当前为 352,扇区剩余空间足够),复用现有 `Load_Database`/`Save_Database`,未新增独立扇区。