对接第 6 台新威上位机（7.6 客户端，走库路线），并修两处对接中暴露的问题

第 6 台（26.8.215.130）：客户端 7.6（inquire 无 cycle_id、getdevinfo 无 port 属性），
服务端 7.6 形态（482 张 data_* 逐点表、visitor@% 可远程只读连）。与 A 那台同类，
因此走 NEWARE_MYSQL，登记为 neware-b（scripts/register-neware-6th-source.sql）。
用生产库适配器实测通过：48 通道、实时值、水位、增量逐点、16 工步、3 循环（效率 91.6%/92.3%）。

对接中暴露并修掉两处：

1. 超时后关闭在途句柄会钉死调用线程（NewareBtsPipeTransport）。
   实测关闭一条"服务端不作答的连接"本身会阻塞，于是超时白设——调用线程照旧被钉死，
   而这个实例是串行执行的，一条不响应的命令足以把该实例之后的所有请求堵住。
   改为在独立守护线程里关句柄、不等它结束。实测：inquiredf 超时 8 秒后调用线程正常返回。

2. 对不支持数据文件命令的客户端发 inquiredf，代价不只是超时（NewareBtsAdapter）。
   实测（7.6.0.1475）：发一条 inquiredf 之后，该接口的 inquire 连续 8 分钟无应答
   （getdevinfo 仍正常），而那台正在跑测试。厂商软件自身不受影响（走另一条内部管道，
   库侧 data_* 持续写入），但这等于干扰了它对外的接口，必须防住。
   现在先探测一次：inquire 应答没有 cycle_id 的客户端**一条数据文件命令都不发**
   （逐点回落轮询槽位、工步层为空）；另加兜底：探测说支持却真发出去无应答时不再重复发。
   探测读不到应答时抛出，以免把"来源不可达"说成"不按行接收"。
   用生产代码在该台验证：实际只发出 [inquire] 一条探测。

battery-device-bts 72 项、后端全量 250 项通过，BUILD SUCCESS。