fix(rf): true single-edge P3.6 trigger + pull-down, restore edge decode

Root cause found via datasheet: PxIM0/PxIM1 has no dual-edge mode, only
falling/rising/low-level/high-level. (IM1=1,IM0=1) was actually
high-level interrupt, refiring continuously for the whole high-pulse
duration (confirmed by scope: no real HF noise, and edge_count=0 when
P3.6 grounded). Fix: start in rising-edge mode, software-toggle to the
opposite edge on every trigger (ping-pong) to emulate true dual-edge
triggering, feeding exact edge direction into the incremental decode
state machine (no glitch filter needed). Also switch P3.6 idle bias
from pull-up to pull-down, since floating-high under the old high-level
mode caused the interrupt-storm boot issue; removed the now-conflicting
pull-up restore in Wakeup_Restore().

work-order/wo-04

@@ -186,6 +186,33 @@
 
 状态：代码已完成，待实机烧录，触发一次真实发射并观察 `[RF-ISR-CHECK]` 日志的 `delta` 是否稳定等于 50。
 
+**实测结果**：连续 4 次独立发射，`delta` 稳定在 6963~7043 之间(约理论值 50 的 140 倍，四次误差仅约 1%)，远超"偶发毛刺"能解释的量级，且波动极小，不像随机噪声，更像由代码本身某个确定性行为决定。用户随后用示波器直接实测 P3.6 波形，**确认没有对应的高频噪声/振铃**，彻底排除了 2.6/2.7 节以来"信号有毛刺、需要软件去抖"的整个分析方向。
+
+### 2.9 真正根因定位：`PxIM0/PxIM1` 没有"双边沿触发"模式，`(1,1)` 实际是"高电平中断"
+
+在排除毛刺假设后，用户质疑"会不会中断接错了引脚"。核对 `App/isr_jump.asm`/`P3IM0`/`P3IM1`/`P3INTE` 全仓库唯一赋值点、原理图 Pin19=P3.6=RF_RX_DATA 网络标签，确认引脚本身没有接错。随后查阅《STC32G 系列技术手册》"15.1.3 端口中断模式配置寄存器 (PxIM0，PxIM1)"真值表，发现关键事实：
+
+| PnIM1.x | PnIM0.x | 中断模式 | 掉电唤醒支持 |
+|---|---|---|---|
+| 0 | 0 | 下降沿中断 | 支持 |
+| 0 | 1 | 上升沿中断 | 支持 |
+| 1 | 0 | 低电平中断 | 不支持 |
+| 1 | 1 | 高电平中断 | 不支持 |
+
+这颗芯片的端口中断硬件**只有下降沿/上升沿/低电平/高电平四选一，根本没有"双边沿都触发"这个模式**。而 `RF_Init()` 里一直写的是 `P3IM1|=0x40; P3IM0|=0x40;`——对照表格，这实际配置的是**高电平中断**，跟代码注释"双边沿触发"完全对不上：只要 P3.6 处于高电平，中断就会在整段高电平期间被硬件持续、大量地重新触发，这才是边沿计数远超协议理论值(50)、且四次测量高度稳定(由代码执行速度决定，而非随机噪声)的真正原因，从一开始就与信号质量无关。用户随后做了接地实验直接验证：P3.6 直接短接到地，`isr_edge_count` 恒为 0(满足不了"高电平"这个触发条件)；正常收码时该值持续变化——与"高电平中断"模型完全吻合。
+
+同时发现一个关联问题：`P3.6` 还兼职做掉电唤醒源，而上表显示"高电平中断"**不支持掉电唤醒**，说明之前 `P3.6` 唤醒功能大概率也没有真正按预期工作。
+
+### 2.10 修复：软件乒乓单边沿切换模拟双边沿触发 + P3.6 内部下拉
+
+由于硬件不提供真正的双边沿模式，改为标准的软件模拟方案：`RF_Init()` 里初始配置成单一边沿(上升沿)触发；`RF_HandleEdgeInterrupt()` 每次触发后，先根据触发前的 `P3IM0` 值判断刚刚发生的是上升沿还是下降沿(乒乓切换保证了高/低电平段严格交替出现，不需要再读引脚电平猜测方向)，再立即把 `P3IM0` 翻转到相反边沿，为下一次真实翻转做准备。这样每次真实电平翻转都会精确触发一次中断，不多不少，不再需要任何毛刺过滤器。
+
+顺带修正一个关联的悬空钳位问题：`P3.6` 内部上拉 (`P3PU`) 改为内部下拉 (`P3PD`)，在 `RF_Init()` 里一次性永久开启——`SHUT=1`(芯片关断)时 `DATA` 脚高阻悬空，配合"高电平中断"误配置，之前的上拉方案正好会把悬空态钳在会触发中断的那一侧，是当年开机中断风暴/背光闪烁问题的更深层成因；改用下拉后悬空态落在"不触发"一侧。同时清理了 `App/system.c` 里 `Wakeup_Restore()` 遗留的、每次唤醒都重新打开 P3.6 上拉的代码——留着会导致上拉和下拉同时使能、相互打架，现已移除(下拉在 `RF_Init()` 一次性配置好，Power Down 期间 SFR 状态不丢失，休眠/唤醒不需要重新配置)。
+
+改动范围：`Drivers/rf.c`(重写 `RF_Init` 引脚上下拉与初始边沿配置、重写 `RF_HandleEdgeInterrupt` 为乒乓单边沿版本、恢复三态增量解码状态机 `RF_HandleHighSegmentEnd`/`RF_HandleLowSegmentEnd`、`RF_CheckDecodeWatchdog`、非阻塞 `EV1527_Decode()`，移除本次调试实验用的 `GetPulseDuration`/阻塞轮询版 `EV1527_Decode`)、`Drivers/rf.h`(同步更新函数注释)、`App/main.c`(`Port3_Isr` 注释同步)、`App/system.c`(`Wakeup_Restore()` 移除上拉恢复)。
+
+状态：代码已完成，待实机烧录验证——重点关注解码是否能稳定成功，以及 `RF_PrintDebugCounters()` 里 `aborts` 计数是否合理(偶发因真实干扰打断可以理解，持续大量 abort 则说明状态机或阈值仍有问题)。
+
 ## 六、阶段 1 实现备注
 
 * 语言字节与传感器数据库共用同一 Flash 扇区(偏移地址为 `sizeof(sensor_list)`,当前为 352,扇区剩余空间足够),复用现有 `Load_Database`/`Save_Database`,未新增独立扇区。