fix: 给「寻路状态」进度日志加节流（1.11.1）

mineflayer-pathfinder 每用满一个 tick 的计算预算（tickTimeout，默认 40ms）就发一次
path_update，而原来的处理函数每次都记一条 —— 实测 4 分钟写了 3893 条（约 16 条/秒）。
既淹没了真正有用的日志（按 120 字节/行算一天能写上百 MB，而本服磁盘只剩 2.4G），
也让「寻路到底卡在哪」更难看清。

现在只在三种情况下记：
1. 状态发生变化（partial → success / noPath / timeout）—— 最要紧的信号；
2. 距上一条超过 2 秒；
3. 已探索节点数比上一条多出 1000 以上 —— 长规划里仍能看出推进速度，
   不丢定位卡死所需的信息。

测试 480 → 481。

test/pathingService.test.js

@@ -50,6 +50,38 @@ test('高度偏好默认关闭：它的启发值会破坏 partial 路径的终
     `高处节点的启发值 ${farButHigh} 不大于低处近节点的 ${nearButLow}，正是问题所在`);
 });
 
+test('寻路状态日志被节流：进度刷屏不会把日志写爆', () => {
+  // mineflayer-pathfinder 每用满一个 tick 的计算预算（tickTimeout，默认 40ms）
+  // 就发一次 path_update。不节流时实测 4 分钟写了 3893 条「寻路状态」，
+  // 既淹没真正有用的日志（一天上百 MB，本服磁盘本就只剩 2.4G），
+  // 也让「寻路卡在哪」更难看清。
+  const bot = new FakeBot({ x: 0.5, y: 64, z: 0.5 });
+  bot.pathfinder = {
+    setMovements: () => {},
+    setGoal: () => {},
+    thinkTimeout: 0,
+    tickTimeout: 0,
+    searchRadius: 0
+  };
+  const logs = [];
+  const logger = { log: (msg) => logs.push(String(msg)), error: () => {}, list: () => [], clear: () => {} };
+  const service = new PathingService(bot, defaultConfig(), logger);
+  service.configure();
+
+  // 模拟一次长规划：状态一直是 partial、节点数快速增长
+  for (let i = 0; i < 300; i++) {
+    bot.emit('path_update', { status: 'partial', visitedNodes: i * 20, cost: 90 });
+  }
+  const progressLogs = logs.filter((m) => m.includes('寻路状态'));
+  assert.ok(progressLogs.length >= 2, `不应把进度信息完全丢掉，实际 ${progressLogs.length} 条`);
+  assert.ok(progressLogs.length <= 12, `300 次 partial 应被节流到十几条以内，实际 ${progressLogs.length} 条`);
+
+  // 状态变化是最要紧的信号，必须立刻记一条
+  logs.length = 0;
+  bot.emit('path_update', { status: 'success', visitedNodes: 6100, cost: 90 });
+  assert.strictEqual(logs.filter((m) => m.includes('寻路状态')).length, 1, '状态变化要立刻记录');
+});
+
 // ==================== 长距离分段寻路 ====================
 //
 // mineflayer-pathfinder 只能规划已加载区块范围（实测线上约 8 区块 ≈ 130 格），