fix(devicebridge): 修复设备反复掉线/静默失联 —— ping 路径断连 + bind 结果无人处理

用户要求全面修复「设备桥自动链接」这条链路上的问题。三个真实缺陷，
前两个是**服务端/客户端真 bug**（生产日志实证），第三个是我起初误判的。

## 缺陷 1（最严重）：未 bind 时收到 ping → 服务端直接关连接

原实现：
    err := r.wsWriteLocked(curID, writePong)
    if err != nil { return }   // ← 关连接

而 conns 表**只在 bind 成功后才写入**（bind 前刻意不暴露连接给查询/命令
路径）。于是「握手完成、bind 尚未到达」这个窗口里来的 ping 找不到写入口，
函数返回错误，读循环 return —— 把连接关掉了。

生产后果（journalctl 实证）：客户端每 30s ping 一次，只要有一次落在未 bind
窗口就断连。日志里同一设备 20 秒内多次 "ws connected"，online/offline 与
输出通道注销/注册反复交替：

  17:29:14 ws connected → 17:29:17 ws connected → 17:29:24 ws connected
  → 17:29:29 → 17:29:35 → 17:29:40 online → 17:30:18 offline → ...循环

修法：pong 直接写本连接的 writer。此时该连接尚未进入 conns（没有 Push* 会
碰它的 writer），不存在并发写风险；已 bind 时才取写锁（Push* 可能正在写
同一 buffer）。

判据 TestPingBeforeBindDoesNotDropConnection 直打 bug 点（只握手、不发
hello/bind、发 ping、要求 pong），修复前报 `EOF`，修复后通过。

## 缺陷 2：bind_ack 的 ok 完全没被检查 → 失败静默失联

原实现（客户端）：
    case "hello_ack", "bind_ack":
        log.Printf("... device=%v", msg["device"])

两处错：
- **取错字段**：服务端成功时回 {"op":"bind_ack","ok":true}，没有 device
  字段，于是日志永远显示 `bind_ack device=<nil>`。这让我起初误判成"绑定
  失败"，实际连接是好的（直连与经反代现象完全一致）。
- **不看 ok**：bind 被拒时服务端回 ok:false + error 并关闭连接，客户端既不
  报错也不重连，设备静默失联 —— TCP/WS 通但从未登记进网关。

修法：分别处理两种 ack；bind 判 ok，失败记原因并通知宿主。新增
Bridge.Bound() / BindError() / OnBoundState()：**连接成功 ≠ 设备可用**，
只看连接状态的健康检查会给出假阳性。

判据 TestBindFailureIsObservable / TestBindStateCallback。

## 缺陷 3：-chat 一次性模式下桥存活时间过短

不是我最初以为的"bind 失败"。真因：`-chat` 走进 oneshot 后立刻 return，
触发 defer stopDeviceBridge()，桥只活几百毫秒，设备来不及完成 hello→bind。

修法：退出前等 bind 确认（最多 3s）；bind 明确被拒则打印原因，不静默丢弃。

## 真实验收（隔离实例，命名 netns + 独立 data + 18080）

真 waiter 经**反代自动发现**连接，保持连接期间查询服务端：

  device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
  bind 成功，设备已登记
  /api/v1/device/online → waiter-mainserver, online=true, caps=[11 项]

长连接稳定性：70 秒（跨 2 个 ping 周期）三次采样设备始终在线，
无 read loop exit / bind rejected 日志。

## 附：反代通路本身的判定性对照

裸客户端（直接构造 hello/bind 帧）**经反代**与**直连 9890** 返回逐字节
一致（bind_ack ok=true、设备注册、online=true）。所以这条链路上反代
不背锅，问题全在 remotedevice 服务端与客户端自身。

cmd/waiter/main.go

@@ -205,6 +205,18 @@ func main() {
 	}
 
 	if oneShotMsg != "" {
+		// ★ -chat 是一次性问答，会立刻走到上面的 return 并触发
+		// defer stopDeviceBridge()，桥的生命周期只有几百毫秒。
+		//
+		// 后果：设备来不及完成 hello→bind 登记就已断开，服务端列表里永远
+		// 看不到它（实测：`device bridge active` 打印了、bind_ack 也收到了，
+		// 但 /api/v1/device/online 始终为空）。
+		// 这不是桥的错 —— 用裸客户端把 hello/bind 发完并保持连接，同一实例
+		// 上设备立刻出现在列表里（已验证）。
+		//
+		// 等待 bind 确认（或短暂超时）再退出：既让登记完成，也不把一次性
+		// 命令拖长。bind 失败要明说，而不是静默丢掉设备。
+		waitDeviceBind(3 * time.Second)
 		oneshot(state, oneShotMsg)
 		return
 	}
@@ -499,3 +511,26 @@ func printServerEventColored(rl respLine, raw string) {
 		fmt.Printf("%s%s%s\n", clearLine, text, colorReset)
 	}
 }
+
+// waitDeviceBind 等待服务端确认 bind（最多 timeout），返回是否确认。
+//
+// 用于一次性命令（-chat）：桥启动后立刻退出会让设备来不及登记。
+// 超时不报错（服务端可能只是慢），bind 明确被拒则打出来 —— 那通常意味着
+// 设备令牌不对或设备未授权，用户需要知道，而不是以为「桥起来了就好了」。
+func waitDeviceBind(timeout time.Duration) bool {
+	if deviceBridge == nil {
+		return false
+	}
+	deadline := time.Now().Add(timeout)
+	for time.Now().Before(deadline) {
+		if deviceBridge.Bound() {
+			return true
+		}
+		if reason := deviceBridge.BindError(); reason != "" {
+			printlnC(colorYellow, "device bridge bind rejected: "+reason)
+			return false
+		}
+		time.Sleep(50 * time.Millisecond)
+	}
+	return deviceBridge.Bound()
+}