fix(cluster): 停用的转发会在重启后自己复活 + 令牌轮转日志刷屏

从线上三节点（192.168.2.{30,106,60}）的日志里挖出四个问题，本轮修三个。

## 1. 停用的转发会复活（功能性缺陷，实测仍在发生）

线上现象：`minecraft` 在 store 里 disabled=1，worker 却仍在跑，今天
09:46 还在刷 `connect to local service [192.168.2.60:25565]: connection
refused` —— 对着一个用户刻意没启的本地服务死刷。同时三台 logs 里躺着
13956 / 3769 条 `proxy [x] already exists`，每 33 秒一轮。

四处叠加导致：
- stopForward 先读 link，再 SetLinkDisabled(true)，然后把**改之前**的
  副本交给 RevokeTask ⇒ published task 带 disabled=false（实测 id/flag
  都对不上：topology 里 link.id=223，store 里同一行是 199）
- ClaimFn **无条件** SetLinkDisabled(...,false)。原意是"重新认领时清掉
  停用标记"，但启动 reconcile 只要 worker 不在就重新 Claim ⇒ 每次重启
  都是"先清标记再起 worker"
- RevokeFn 停了 worker 却**没删 topology 条目**，条目活过 worker
- 于是下次重启 reconcile 看到"owned 但 worker 不在"→ 再次 Claim → 死循环

修法（把 disabled 的所有权交回两个用户动作）：
- Claim **只读** disabled 决定要不要起 worker；为 true 时连 topology
  条目一起摘掉，绝不复活
- 启动 reconcile 先按 store 跳过 disabled 的条目（省掉无谓的
  claim→skip 往返）
- RevokeFn 除停 worker 外，同时 RemoveTopologyEntry —— 撤销必须是
  完整退役，不能只是"停一下"
- stopForward 把 Disabled=true 随 task 发布出去，让持有该转发的节点
  即使本地 store 行陈旧也能判断这次停用是用户主动的

## 2. 令牌轮转日志零信息量却占满磁盘

每轮固定 3 行（OnToken cycle=N / forward cycle=N / token-send -> 200），
2 轮/秒，实测本机 **355 行/分钟、7 天 357 万行**，把真事件全淹了。
同一份信息（cycle / lastSync / roundDelayMs / 成员存活）本来就能从
GET /api/manager/cluster/ring 结构化拿到。

加 W4F_DEBUG 开关（沿用项目既有 W4F_ 前缀约定）：稳态三行降级为 debug、
默认关闭；**失败路径一律保留** —— 发送失败、陈旧令牌、非 2xx 正是别人
grep 的对象，静音它们是坏交易。实测同样 12 秒：36 行 → 4 行。

## 3. Link.ID 在 ReplaceLinks 之后必然失效

ReplaceLinks 是 DELETE + 重新 INSERT，sqlite 给每行**新的自增 id**。
任何在改写前捕获的 Link（典型：随 token 环跑的 Link）手里的 id 要么查无
此行，要么命中另一条转发 —— 实测捕获 alpha id=1，改写后新表是 3/4/5，
GetLink(1) 直接落空。

新增 LinkByTriple(local, remote, port) 按自然键查（业务代码本来就一律用
这个三元组标识转发），并把 claim/reconcile 切过去。查无行返回
(Link{}, false, nil) 而非 error：新建的转发没有行，应当照常启动。

## 4. homeagent_device 孤儿（已澄清，非独立缺陷）

它 disabled=1 且从不在 topology 里，是缺陷 1 的另一面（停用标记没进
token），随本次修复覆盖，无需单独处理。

## 测试

新增 4 个测试文件，重点是**验证测试本身抓得住 bug**：
- 临时回退 `ln.Disabled = true` 这行 → TestStopForwardPublishesDisabled-
  FlagInRevokeTask 如期变红，还原后变绿
- ⚠️ 第一版回归测试只断言 store 层，是**假绿**：newTestHandler 的 Ring
  为 nil，RevokeTask 那条（真正坏掉的）路根本没执行。补了带 ring 的
  newRingTestHandler，直接断言**发布出去的 task 上的 flag**
- LinkByTriple 在 ReplaceLinks 前后保持稳定；GetLink(id) 的失效被固化成
  一个可见的说明性测试
- 停用/start 往返、per-forward 停用不误伤兄弟转发
- 错误路径不静音、W4F_DEBUG 各种取值

go build / go vet / go test ./... 全绿，gofmt 干净。

internal/cluster/ring_engine.go

@@ -182,7 +182,9 @@ func (e *Engine) OnToken(ctx context.Context, tk *Token) (*Token, error) {
 	if tk.SentAt > e.lastTokenAt {
 		e.lastTokenAt = tk.SentAt
 	}
-	log.Printf("ring[%s] OnToken cycle=%d", e.ID, tk.Cycle)
+	// Per-round heartbeat — steady state, no information. See debug.go: this
+	// fired ~2x/second and dominated the journal on every node.
+	debugToken("ring[%s] OnToken cycle=%d", e.ID, tk.Cycle)
 
 	// Parallel rhythm timer: operations run while the pace clock ticks.
 	// Delay scales with alive node count (more nodes → lower per-hop delay,
@@ -792,6 +794,14 @@ func (e *Engine) RemoveNode(nodeID string) *Task {
 	return e.state.AddRemoveNode(nodeID)
 }
 
+// RemoveTopologyEntry drops the active topology entry for a forward identified
+// by its natural key. Exposed so the app's claim path can retire an entry it
+// refuses to serve (see ClaimFn: a disabled forward must stop looking active,
+// otherwise the startup reconcile keeps re-claiming it on every restart).
+func (e *Engine) RemoveTopologyEntry(local, remote string, port int) bool {
+	return e.state.RemoveTopology(local, remote, port)
+}
+
 // RevokeTask publishes a revocation for an established forward through the
 // same token channel; the owning node stops the worker and drops topology.
 func (e *Engine) RevokeTask(local store.Local, remote store.Remote, link store.Link) *Task {